perm filename CLCLEA.MSG[COM,LSP]5 blob
sn#845570 filedate 1987-09-04 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00314 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00045 00002
C00046 00003 ∂23-Apr-87 1359 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue DEFVAR-INIT-TIME (Version 1)
C00051 00004 ∂23-Apr-87 1432 gls@Think.COM AREF-1D
C00053 00005 ∂23-Apr-87 1447 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
C00059 00006 ∂23-Apr-87 1453 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
C00062 00007 ∂23-Apr-87 2031 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
C00065 00008 ∂23-Apr-87 2150 Moon@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C00068 00009 ∂23-Apr-87 2157 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-NOT-ADJUSTABLE
C00071 00010 ∂23-Apr-87 2209 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D
C00073 00011 ∂23-Apr-87 2255 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
C00076 00012 ∂24-Apr-87 1326 masinter.PA@Xerox.COM Re: Issue DEFVAR-INIT-TIME (Version 1)
C00078 00013 ∂24-Apr-87 1846 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-NOT-ADJUSTABLE
C00083 00014 ∂25-Apr-87 0021 gls@think.com DELETE, SORT, ADJUST-ARRAY considered harmful
C00086 00015 ∂27-Apr-87 1151 Masinter.pa@Xerox.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
C00088 00016 ∂27-Apr-87 1312 Masinter.pa@Xerox.COM status
C00097 00017 ∂28-Apr-87 1114 KMP@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00117 00018 ∂28-Apr-87 1334 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00131 00019 ∂28-Apr-87 1916 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00136 00020 ∂28-Apr-87 2204 masinter.PA@Xerox.COM Re: Issue: PROCLAIM-LEXICAL
C00139 00021 ∂29-Apr-87 0641 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PROCLAIM-LEXICAL
C00145 00022 ∂29-Apr-87 0938 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
C00154 00023 ∂29-Apr-87 0943 KMP@STONY-BROOK.SCRC.Symbolics.COM status of DEFVAR-INIT-TIME
C00157 00024 ∂29-Apr-87 1024 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00159 00025 ∂29-Apr-87 1025 KMP@STONY-BROOK.SCRC.Symbolics.COM Procedure for Steele's proposed clarifications
C00162 00026 ∂29-Apr-87 1131 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
C00166 00027 ∂29-Apr-87 1234 Pavel.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
C00168 00028 ∂29-Apr-87 1246 KMP@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
C00175 00029 ∂29-Apr-87 1337 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY (Version 5)
C00193 00030 ∂29-Apr-87 1404 gls@Think.COM AREF-1D
C00195 00031 ∂29-Apr-87 1406 gls@think.com AREF-1D
C00197 00032 ∂29-Apr-87 1501 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
C00199 00033 ∂29-Apr-87 1722 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00204 00034 ∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
C00206 00035 ∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
C00208 00036 ∂29-Apr-87 1844 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
C00211 00037 ∂29-Apr-87 1926 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00216 00038 ∂29-Apr-87 1951 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00221 00039 ∂30-Apr-87 0053 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00225 00040 ∂30-Apr-87 1425 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
C00227 00041 ∂30-Apr-87 1429 Masinter.pa@Xerox.COM Re: Procedure for Steele's proposed clarifications
C00229 00042 ∂30-Apr-87 1459 Masinter.pa@Xerox.COM Re: Status of IGNORE-ERRORS
C00231 00043 ∂30-Apr-87 1502 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
C00233 00044 ∂30-Apr-87 1638 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00238 00045 ∂30-Apr-87 1818 Masinter.pa@Xerox.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00241 00046 ∂30-Apr-87 1901 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00246 00047 ∂01-May-87 1536 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00250 00048 ∂01-May-87 1656 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00261 00049 ∂01-May-87 1933 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00264 00050 ∂01-May-87 1947 FAHLMAN@C.CS.CMU.EDU ADJUST-ARRAY-NOT-ADJUSTABLE
C00266 00051 ∂01-May-87 2030 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00270 00052 ∂01-May-87 2037 FAHLMAN@C.CS.CMU.EDU UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C00274 00053 ∂01-May-87 2115 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00277 00054 ∂01-May-87 2128 FAHLMAN@C.CS.CMU.EDU Issue DEFVAR-INIT-TIME (Version 1)
C00279 00055 ∂01-May-87 2145 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00283 00056 ∂02-May-87 0707 FAHLMAN@C.CS.CMU.EDU DELETE, SORT, ADJUST-ARRAY considered harmful
C00286 00057 ∂02-May-87 1143 FAHLMAN@C.CS.CMU.EDU IF-BODY (Version 5)
C00293 00058 ∂02-May-87 1220 FAHLMAN@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00296 00059 ∂02-May-87 1313 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00302 00060 ∂02-May-87 1324 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 2)
C00304 00061 ∂02-May-87 1340 FAHLMAN@C.CS.CMU.EDU PRINC-CHARACTER (Version 2)
C00305 00062 ∂02-May-87 1616 JAR@AI.AI.MIT.EDU Is JAR on CL-CLEANUP now? Yes.
C00306 00063 ∂02-May-87 1655 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00312 00064 ∂02-May-87 1720 FAHLMAN@C.CS.CMU.EDU Is JAR on CL-CLEANUP now? Yes.
C00314 00065 ∂02-May-87 1855 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00320 00066 ∂04-May-87 1056 Masinter.pa@Xerox.COM Issue priority
C00322 00067 ∂04-May-87 1423 KMP@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C00333 00068 ∂04-May-87 1919 FAHLMAN@C.CS.CMU.EDU Issue priority
C00336 00069 ∂05-May-87 1416 pedersen.pa@Xerox.COM Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00340 00070 ∂10-May-87 1154 FAHLMAN@C.CS.CMU.EDU [RAM: exiting from unwind protects]
C00347 00071 ∂11-May-87 1051 RPG Draft of revised FUNCTION-TYPE
C00361 00072 ∂11-May-87 1256 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
C00373 00073 ∂11-May-87 1420 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
C00380 00074 ∂11-May-87 1443 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
C00384 00075 ∂11-May-87 1502 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
C00389 00076 ∂11-May-87 1803 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
C00391 00077 ∂11-May-87 1807 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-STREAM
C00392 00078 ∂11-May-87 1901 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00403 00079 ∂11-May-87 1907 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
C00405 00080 ∂11-May-87 1940 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
C00406 00081 ∂12-May-87 0728 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00410 00082 ∂12-May-87 0930 Gregor.pa@Xerox.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00411 00083 ∂12-May-87 1158 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00417 00084 ∂12-May-87 1258 gls@Think.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00419 00085 ∂12-May-87 1430 gls@Think.COM Issue: FUNCTION-TYPE (version 3)
C00420 00086 ∂12-May-87 1456 gls@Think.COM Issue: PATHNAME-SYMBOL
C00421 00087 ∂12-May-87 1457 gls@Think.COM Issue: PATHNAME-STREAM
C00422 00088 ∂12-May-87 2104 Moon@STONY-BROOK.SCRC.Symbolics.COM [RAM: exiting from unwind protects]
C00437 00089 ∂12-May-87 2124 Moon@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00440 00090 ∂13-May-87 0012 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
C00448 00091 ∂13-May-87 0914 RPG FUNCTION-TYPE and Archives
C00451 00092 ∂13-May-87 1133 @ALLEGHENY.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM FUNCTION-TYPE, archives, and Macsyma
C00455 00093 ∂13-May-87 1626 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE and Archives
C00458 00094 ∂13-May-87 2121 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
C00466 00095 ∂13-May-87 2158 Moon@STONY-BROOK.SCRC.Symbolics.COM looping in unwind-protect cleanups
C00471 00096 ∂14-May-87 1039 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
C00475 00097 ∂14-May-87 1046 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
C00478 00098 ∂14-May-87 1051 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
C00480 00099 ∂15-May-87 2144 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00498 00100 ∂16-May-87 0302 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
C00500 00101 ∂17-May-87 1447 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00507 00102 ∂17-May-87 1931 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
C00519 00103 ∂17-May-87 1944 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE and Archives
C00522 00104 ∂18-May-87 1344 gls@Think.COM Issue: PROCLAIM-LEXICAL
C00524 00105 ∂18-May-87 1529 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00526 00106 ∂19-May-87 1316 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-NEGATIVE-PARAMETERS
C00530 00107 ∂19-May-87 1739 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
C00538 00108 ∂19-May-87 1801 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00546 00109 ∂19-May-87 1812 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
C00552 00110 ∂26-May-87 1431 Masinter.pa@Xerox.COM administrative
C00555 00111 ∂28-May-87 2233 JAR,KMP@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
C00560 00112 ∂29-May-87 2113 Masinter.pa@Xerox.COM barrage of mail coming
C00562 00113 ∂29-May-87 2114 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT
C00570 00114 ∂29-May-87 2116 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
C00575 00115 ∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: DO-SYMBOLS-DUPLICATES (Version 2)
C00582 00116 ∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 5)
C00590 00117 ∂29-May-87 2119 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
C00592 00118 ∂29-May-87 2119 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (version 4)
C00607 00119 ∂29-May-87 2121 Masinter.pa@Xerox.COM Re: Issue GC-MESSAGES (Version 1)
C00611 00120 ∂29-May-87 2121 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
C00616 00121 ∂29-May-87 2122 Masinter.pa@Xerox.COM IGNORE-ERRORS (Version 4)
C00622 00122 ∂29-May-87 2123 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
C00635 00123 ∂29-May-87 2124 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
C00639 00124 ∂29-May-87 2125 Masinter.pa@Xerox.COM Issue: PATHNAME-SYMBOL (Version 2)
C00645 00125 ∂29-May-87 2127 Masinter.pa@Xerox.COM Status [Part 1]
C00652 00126 ∂29-May-87 2128 Masinter.pa@Xerox.COM ***BALLOT *** PART 1 *** BALLOT *** PART 1 ***
C00656 00127 ∂29-May-87 2133 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 5)
C00661 00128 ∂29-May-87 2214 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)
C00669 00129 ∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: TAILP-NIL
C00672 00130 ∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
C00674 00131 ∂29-May-87 2310 Masinter.pa@Xerox.COM Status, Part 2
C00677 00132 ∂29-May-87 2310 Masinter.pa@Xerox.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
C00679 00133 ∂30-May-87 0715 MATHIS@ADA20.ISI.EDU Re: barrage of mail coming
C00681 00134 ∂31-May-87 2051 masinter.pa@Xerox.COM ballots, meeting, etc.
C00683 00135 ∂01-Jun-87 1217 JAR@AI.AI.MIT.EDU Status, Part 2
C00685 00136 ∂01-Jun-87 1449 edsel!kent-state!eb@navajo.stanford.edu AREF-1D
C00687 00137 ∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
C00689 00138 ∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu ***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***
C00694 00139 ∂01-Jun-87 1650 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
C00696 00140 ∂01-Jun-87 1715 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: FUNCTION-TYPE (version 4)
C00699 00141 ∂01-Jun-87 1810 Pavel.pa@Xerox.COM AREF-1D
C00700 00142 ∂01-Jun-87 1822 Pavel.pa@Xerox.COM DO-SYMBOLS-DUPLICATES
C00703 00143 ∂01-Jun-87 1830 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
C00705 00144 ∂01-Jun-87 2041 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: TAILP-NIL
C00707 00145 ∂01-Jun-87 2047 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
C00712 00146 ∂01-Jun-87 2050 Moon@STONY-BROOK.SCRC.Symbolics.COM PATHNAME-SYMBOL
C00716 00147 ∂01-Jun-87 2055 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names
C00719 00148 ∂01-Jun-87 2121 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 4)
C00722 00149 ∂01-Jun-87 2122 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
C00724 00150 ∂01-Jun-87 2121 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
C00727 00151 ∂01-Jun-87 2126 Moon@STONY-BROOK.SCRC.Symbolics.COM ***BALLOT ***
C00734 00152 ∂01-Jun-87 2137 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 3)
C00744 00153 ∂01-Jun-87 2151 Moon@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
C00746 00154 ∂01-Jun-87 2152 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
C00750 00155 ∂01-Jun-87 2209 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
C00755 00156 ∂01-Jun-87 2221 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 2)
C00761 00157 ∂02-Jun-87 0041 masinter.pa@Xerox.COM schedule
C00763 00158 ∂02-Jun-87 0226 KMP@STONY-BROOK.SCRC.Symbolics.COM *** BALLOT ***
C00771 00159 ∂02-Jun-87 1016 RPG Issue: FUNCTION-TYPE (version 4)
C00773 00160 ∂02-Jun-87 1148 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
C00778 00161 ∂02-Jun-87 1219 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
C00781 00162 ∂03-Jun-87 0729 gls@Think.COM ***BALLOT *** PART 1 *** My reply
C00785 00163 ∂03-Jun-87 0731 gls@Think.COM DO-SYMBOLS
C00787 00164 ∂03-Jun-87 0733 gls@Think.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
C00788 00165 ∂03-Jun-87 0749 gls@Think.COM June X3J13 meeting
C00789 00166 ∂03-Jun-87 0809 gls@think.com Transitivity of coercions
C00791 00167 ∂03-Jun-87 0926 gls@Think.COM People's names :-)
C00796 00168 ∂03-Jun-87 1101 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
C00798 00169 ∂03-Jun-87 1154 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names :-}
C00801 00170 ∂03-Jun-87 1332 gls@Think.COM DO-SYMBOLS
C00804 00171 ∂03-Jun-87 1906 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
C00808 00172 ∂03-Jun-87 2038 FAHLMAN@C.CS.CMU.EDU PATHNAME-SYMBOL
C00810 00173 ∂03-Jun-87 2104 FAHLMAN@C.CS.CMU.EDU General strategy
C00814 00174 ∂03-Jun-87 2124 FAHLMAN@C.CS.CMU.EDU Ballot, parts 1 and 2
C00820 00175 ∂03-Jun-87 2135 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT
C00823 00176 ∂03-Jun-87 2145 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Version 2)
C00826 00177 ∂03-Jun-87 2201 FAHLMAN@C.CS.CMU.EDU IF-BODY
C00829 00178 ∂03-Jun-87 2232 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 4)
C00834 00179 ∂03-Jun-87 2238 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
C00836 00180 ∂04-Jun-87 0852 RPG FUNCTION-TYPE
C00838 00181 ∂04-Jun-87 1742 Masinter.pa@Xerox.COM Format revisited
C00844 00182 ∂04-Jun-87 1742 Masinter.pa@Xerox.COM AREF-1D (Version 3)
C00850 00183 ∂04-Jun-87 1742 Masinter.pa@Xerox.COM Merging of committees
C00854 00184 ∂04-Jun-87 1856 MATHIS@ADA20.ISI.EDU
C00855 00185 ∂04-Jun-87 1925 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 3)
C00857 00186 ∂04-Jun-87 1933 KMP@STONY-BROOK.SCRC.Symbolics.COM Merging of committees
C00861 00187 ∂05-Jun-87 1808 Masinter.pa@Xerox.COM FORMAT-OP-C (Version 4)
C00870 00188 ∂05-Jun-87 1809 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
C00872 00189 ∂05-Jun-87 1809 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
C00884 00190 ∂05-Jun-87 2113 KMP@STONY-BROOK.SCRC.Symbolics.COM Sigh -- More procedure
C00892 00191 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM Re: Sigh -- More procedure
C00896 00192 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C00905 00193 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM AREF-1D (Version 4)
C00911 00194 ∂05-Jun-87 2209 Masinter.pa@Xerox.COM proposal format (version 10)
C00917 00195 ∂05-Jun-87 2210 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
C00926 00196 ∂05-Jun-87 2235 Masinter.pa@Xerox.COM Re: proposal format (version 10)
C00928 00197 ∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
C00933 00198 ∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Revision 3)
C00938 00199 ∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
C00943 00200 ∂05-Jun-87 2349 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
C00950 00201 ∂06-Jun-87 0000 Masinter.pa@Xerox.COM ***READ ME FIRST ***Status
C00963 00202 ∂06-Jun-87 1412 RPG A Hole in Common Lisp
C00971 00203 ∂06-Jun-87 1630 RPG FUNCTION-TYPE
C00973 00204 ∂06-Jun-87 1802 FAHLMAN@C.CS.CMU.EDU A Hole in Common Lisp
C00980 00205 ∂07-Jun-87 0826 FAHLMAN@C.CS.CMU.EDU Rules
C00983 00206 ∂07-Jun-87 1150 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C00990 00207 ∂07-Jun-87 1259 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C00993 00208 ∂07-Jun-87 1318 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C00996 00209 ∂07-Jun-87 1348 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C00999 00210 ∂07-Jun-87 1603 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 4)
C01001 00211 ∂07-Jun-87 1612 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
C01003 00212 ∂07-Jun-87 1622 RPG Hole
C01005 00213 ∂07-Jun-87 1630 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C01009 00214 ∂07-Jun-87 1632 RPG FUNCTION-TYPE
C01011 00215 ∂07-Jun-87 1648 RPG FUNCTION-TYPE and EuLisp
C01013 00216 ∂07-Jun-87 1753 FAHLMAN@C.CS.CMU.EDU AREF-1D (Version 4)
C01014 00217 ∂07-Jun-87 1755 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Version 6)
C01015 00218 ∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Version 6)
C01016 00219 ∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: DEFVAR-INITIALIZATION (Version 4)
C01017 00220 ∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
C01018 00221 ∂08-Jun-87 0646 gls@Think.COM FORMAT-OP-C (Version 4)
C01019 00222 ∂08-Jun-87 0727 gls@Think.COM Hole
C01023 00223 ∂08-Jun-87 0802 FAHLMAN@C.CS.CMU.EDU Hole
C01025 00224 ∂08-Jun-87 1128 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 1)
C01033 00225 ∂08-Jun-87 1240 RPG Hole
C01035 00226 ∂08-Jun-87 1342 FAHLMAN@C.CS.CMU.EDU Hole
C01038 00227 ∂08-Jun-87 2001 FAHLMAN@C.CS.CMU.EDU Issue: LOAD-TIME-EVAL (Version 1)
C01041 00228 ∂08-Jun-87 2126 KMP@STONY-BROOK.SCRC.Symbolics.COM LOAD-TIME-EVAL
C01044 00229 ∂09-Jun-87 1732 Masinter.pa@Xerox.COM procedural, errors.
C01047 00230 ∂09-Jun-87 1822 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
C01049 00231 ∂09-Jun-87 1835 KMP@STONY-BROOK.SCRC.Symbolics.COM procedural, errors.
C01051 00232 ∂09-Jun-87 1838 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
C01053 00233 ∂09-Jun-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: LOAD-TIME-EVAL (Version 1)
C01060 00234 ∂09-Jun-87 2029 Moon@STONY-BROOK.SCRC.Symbolics.COM Hole
C01063 00235 ∂09-Jun-87 2113 Moon@STONY-BROOK.SCRC.Symbolics.COM A Hole in Common Lisp
C01067 00236 ∂09-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)
C01072 00237 ∂10-Jun-87 1212 Pavel.pa@Xerox.COM Issue: FORMAT-COMMA-INTERVAL
C01078 00238 ∂10-Jun-87 1357 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Issue: FORMAT-COMMA-INTERVAL
C01080 00239 ∂10-Jun-87 1650 FAHLMAN@C.CS.CMU.EDU Issue: FORMAT-COMMA-INTERVAL
C01082 00240 ∂10-Jun-87 1906 Pavel.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
C01084 00241 ∂10-Jun-87 2127 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C01088 00242 ∂10-Jun-87 2129 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C01092 00243 ∂10-Jun-87 2130 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
C01094 00244 ∂10-Jun-87 2131 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
C01097 00245 ∂10-Jun-87 2325 RPG Put Up or Shut Up
C01100 00246 ∂11-Jun-87 0958 kempf%hplabsc@hplabs.HP.COM Re: Issue: LOAD-TIME-EVAL (Version 1)
C01111 00247 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Re: Issue ADJUST-ARRAY-DISPLACEMENT
C01113 00248 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
C01114 00249 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
C01127 00250 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
C01129 00251 ∂11-Jun-87 1726 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
C01133 00252 ∂11-Jun-87 1842 Masinter.pa@Xerox.COM Status
C01146 00253 ∂11-Jun-87 1842 Masinter.pa@Xerox.COM Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
C01148 00254 ∂11-Jun-87 1846 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
C01150 00255 ∂11-Jun-87 2045 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D (Version 2)
C01153 00256 ∂11-Jun-87 2121 FAHLMAN@C.CS.CMU.EDU Status
C01155 00257 ∂12-Jun-87 0939 Masinter.pa@Xerox.COM Re: Hm
C01157 00258 ∂12-Jun-87 1040 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
C01162 00259 ∂12-Jun-87 1906 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE
C01164 00260 ∂12-Jun-87 1943 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-DISPLACEMENT
C01167 00261 ∂12-Jun-87 2255 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
C01170 00262 ∂12-Jun-87 2256 Masinter.pa@Xerox.COM Issue: EVAL-DEFEATS-LINKER
C01181 00263 ∂13-Jun-87 0042 edsel!bhopal!jonl@navajo.stanford.edu Hm
C01184 00264 ∂14-Jun-87 1136 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
C01189 00265 ∂15-Jun-87 1919 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
C01191 00266 ∂15-Jun-87 1920 Masinter.pa@Xerox.COM READ TODAY: Cover letter for mailing to X3J13
C01204 00267 ∂15-Jun-87 1938 FAHLMAN@C.CS.CMU.EDU READ TODAY: Cover letter for mailing to X3J13
C01208 00268 ∂15-Jun-87 2042 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: EVAL-DEFEATS-LINKER
C01217 00269 ∂15-Jun-87 2140 Moon@STONY-BROOK.SCRC.Symbolics.COM READ TODAY: Cover letter for mailing to X3J13
C01220 00270 ∂16-Jun-87 0159 Masinter.pa@Xerox.COM Re: READ TODAY: Cover letter for mailing to X3J13
C01224 00271 ∂16-Jun-87 0608 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 5)
C01250 00272 ∂16-Jun-87 1338 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
C01257 00273 ∂16-Jun-87 1945 edsel!bhopal!jonl@navajo.stanford.edu READ TODAY: Cover letter for mailing to X3J13
C01259 00274 ∂16-Jun-87 2040 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
C01265 00275 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 5)
C01267 00276 ∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
C01271 00277 ∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C01274 00278 ∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C01278 00279 ∂17-Jun-87 1941 edsel!bhopal!jonl@navajo.stanford.edu Issue: EVAL-DEFEATS-LINKER
C01283 00280 ∂18-Jun-87 1126 RPG FUNCTION-TYPE (Version 5)
C01284 00281 ∂18-Jun-87 1132 RPG FUNCTION-TYPE (Version 5)
C01285 00282 ∂19-Jun-87 1429 @RELAY.CS.NET:willc@tekchips.tek.com Re: Issue: EVAL-DEFEATS-LINKER
C01294 00283 ∂19-Jun-87 1737 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
C01299 00284 ∂22-Jun-87 2236 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
C01305 00285 ∂23-Jun-87 0809 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C01308 00286 ∂23-Jun-87 0948 edsel!kent-state!eb@navajo.stanford.edu Issue: FUNCTION-TYPE (Version 5)
C01312 00287 ∂23-Jun-87 1145 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
C01317 00288 ∂23-Jun-87 1538 RAM@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C01324 00289 ∂25-Jun-87 2333 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE: not allowing symbols to be used as functions
C01326 00290 ∂26-Jun-87 1104 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Issue: IF-BODY (Version 7)
C01328 00291 ∂29-Jun-87 2239 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR-DOCUMENTATION (Version 1)
C01332 00292 ∂06-Jul-87 1658 Masinter.pa@Xerox.COM AREF-1D (Version 6)
C01339 00293 ∂13-Jul-87 1257 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
C01341 00294 ∂13-Jul-87 1321 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01349 00295 ∂13-Jul-87 1344 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01357 00296 ∂13-Jul-87 1415 Masinter.pa@Xerox.COM Status
C01371 00297 ∂15-Jul-87 1329 Masinter.pa@Xerox.COM Issue: Pathname-subdirectory-list
C01377 00298 ∂16-Jul-87 1714 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: Pathname-subdirectory-list
C01384 00299 ∂16-Jul-87 1730 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01386 00300 ∂20-Jul-87 2130 edsel!bhopal!jonl@labrea.stanford.edu Apropos case sensitive?
C01391 00301 ∂23-Jul-87 1735 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 2)
C01399 00302 ∂23-Jul-87 1735 Masinter.pa@Xerox.COM Status, clarification list, members
C01401 00303 ∂24-Jul-87 1024 KMP@STONY-BROOK.SCRC.Symbolics.COM OPEN-KEYWORDS
C01405 00304 ∂24-Jul-87 1038 KMP@STONY-BROOK.SCRC.Symbolics.COM Mail from Skona Brittain
C01411 00305 ∂27-Jul-87 1005 KMP@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
C01416 00306 ∂27-Jul-87 1754 FAHLMAN@C.CS.CMU.EDU APPEND-DOTTED
C01417 00307 ∂27-Jul-87 1802 FAHLMAN@C.CS.CMU.EDU [Fahlman: Iteration standard]
C01422 00308 ∂30-Jul-87 1129 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01425 00309 ∂30-Jul-87 1145 FAHLMAN@C.CS.CMU.EDU Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01427 00310 ∂30-Jul-87 1717 Masinter.pa@Xerox.COM Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01430 00311 ∂31-Jul-87 1833 edsel!bhopal!jonl@labrea.stanford.edu Issue KEYWORD-ARGUMENT-NAME-PACKAGE
C01432 00312 ∂05-Aug-87 1931 Moon@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
C01433 00313 ∂14-Aug-87 1651 unido!ztivax!kolb@seismo.CSS.GOV Redefinition of system functions
C01437 00314 ∂14-Aug-87 2055 FAHLMAN@C.CS.CMU.EDU Redefinition of system functions
C01440 ENDMK
C⊗;
∂23-Apr-87 1359 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue DEFVAR-INIT-TIME (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 13:59:21 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123216; Thu 23-Apr-87 16:59:34 EDT
Date: Thu, 23 Apr 87 16:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DEFVAR-INIT-TIME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating
the form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE
form is not evaluated unless it is used; this fact is useful if
evaluation of the INITIAL-VALUE form does something expensive like
create a large data structure.''
Although I think the original CL designers all knew what this wording
was intended to mean, I have discovered people who have misinterpreted
the "unless it is used" to mean "unless the variable is used" rather
than "unless the initial-value is to be used". The problem is that the
"it" is ambiguous.
Having made this false assumption, the people I talked to thought --
and understandably (if lamentably) so -- that they wouldn't know if
the variable was to be used until the code ran, so they had the model
that the intention was to provide a kind of lazy initialization that
happened upon the variable's first unbound reference. This confusion
appears to have been further supported by the additional verbiage about
not creating expensive structures that are not needed.
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all).
Rationale:
I think it was clear at design time that this was intended. The manual
should therefore be clear.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
The misinterpretation is much harder to implement than the proposed
interpretation. Adoption of the changes should be straightforward.
Benefits:
This clarification makes the semantics of an important primitive
more well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
KMP thinks this clarification is important.
∂23-Apr-87 1432 gls@Think.COM AREF-1D
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:32:25 PDT
Received: from johannes-scotus-erigena by Think.COM via CHAOS; Thu, 23 Apr 87 16:36:10 EST
Date: Thu, 23 Apr 87 17:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>
Note that I had proposed something like this to be called
AREF-ROW-MAJOR-ORDER. It may be that that proposal had
some relevant material that KMP might want to take into account.
Then again, maybe he already did. That name is too long,
but I feel that the row-majorness should be part of the name.
How about ROW-MAJOR-AREF? But I don't feel strongly about it.
Otherwise I support the proposal.
Ah. I recall that perhaps I had suggested having also
a function ROW-MAJOR-INDEX that takes an array and a bunch
of subscripts, just like AREF, and returns the row-major
index of that element.
--Guy
∂23-Apr-87 1447 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:47:28 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123309; Thu 23-Apr-87 17:46:56 EDT
Date: Thu, 23 Apr 87 17:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: GC-MESSAGES
References: None
Category: ENHANCEMENT
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Although there is no standard interface to the garbage collector,
it is common for there to be a garbage collector in nearly every system.
In many systems, these do unsolicited typeout which obstructs program
typeout in unpredictable ways.
Proposal (GC-MESSAGES:FLAG-VARIABLE):
Make a variable called *GC-MESSAGES* which controls GC message typeout.
Possible values of this stream include:
T Standard notifications (typically to *TERMINAL-IO*).
NIL No notifications.
Since not all implementations could allow an arbitrary user-supplied
stream for use as a value of *GC-MESSAGES* (because streams might cons
and consing might be illegal at the time of the message), this cannot
be offered as an option. However, this would be a reasonable
implementation-dependent extension in some systems, so we should offer
it as an option.
In multi-processed, shared-address space implementations, if the GC is
going to type a message on a stream that belongs to some other process
(or otherwise ``notify'' the process, to use Lisp Machine terminology),
the value of *GC-MESSAGES* in the process being notified should be used
rather than the value in the current process so that this variable can
be usefully bound by user programs.
Permit that as an act of desperation, shortly before running completely
out of space when *GC-MESSAGES* is NIL, the GC may notify the user
that he is about to lose (in spite of the fact that he has seemingly
asked to lose). This permission is important so that people don't feel
afraid to bind *GC-MESSAGES* to NIL to suppress frequent messages
only for fear that they might not get critical last minute information
that says it's time to do drastic cleanup action.
Rationale:
Application programs which do display (especially display which conses)
need a way of deferring GC warnings that might ruin the display.
Current Practice:
This functionality is provided in some form or another by a number of
implementations.
Zetalisp currently offers SI:GC-REPORT-STREAM which can be set to T, NIL,
or a stream. It provides useful flexibility and is used by quite a number
of users.
Other systems provide ways of enabling or disabling the messages, or of
customizing the message which is typed out.
Adoption Cost:
The set of places in which the GC does typeout is probably very
restricted, so finding them and changing them to be appropriately
conditionalized is probably not a lot of work.
Benefits:
This would allow the user some portable control over a common feature which
cannot currently be controlled in a portable way.
Conversion Cost:
This is an upward compatible change.
Aesthetics:
No significant impact.
Discussion:
MACSYMA needs this (so it can bind it to NIL). Its display often does
consing. In some implementations this can cause a GC, which can in turn
spoil the carefully crafted display.
∂23-Apr-87 1453 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:53:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123312; Thu 23-Apr-87 17:50:35 EDT
Date: Thu, 23 Apr 87 17:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: Guy Steele <gls@Think.COM>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>
Message-ID: <870423175014.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 23 Apr 87 17:33 EDT
From: Guy Steele <gls@Think.COM>
Note that I had proposed something like this to be called
AREF-ROW-MAJOR-ORDER. It may be that that proposal had
some relevant material that KMP might want to take into account.
Then again, maybe he already did. That name is too long,
but I feel that the row-majorness should be part of the name.
How about ROW-MAJOR-AREF? But I don't feel strongly about it.
Otherwise I support the proposal.
row-major-aref or aref-row-major would be good names. I think
KMP's suggested function is sufficiently specialized that it does
not need an especially short name.
Ah. I recall that perhaps I had suggested having also
a function ROW-MAJOR-INDEX that takes an array and a bunch
of subscripts, just like AREF, and returns the row-major
index of that element.
array-row-major-index is already in the language.
∂23-Apr-87 2031 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 20:31:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123639; Thu 23-Apr-87 23:31:18 EDT
Date: Thu, 23 Apr 87 23:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870423233110.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This seems a little short-sighted. GC messages aren't necessarily the
only unsolicited messages. In the example application you gave, there
is no reason to treat GC messages differently from other messages.
Also, a simple on/off switch may be a bit too simple. Not all systems
have windows, but for the ones that do a three-state switch could be
defined in an implementation-independent way: (1) turn the messages off,
(2) put them in the typescript, (3) make them visible to the user in a
way that doesn't interfere with the typescript. Even some
teletype-oriented systems are able to implement option 3.
In some systems it may not be possible to implement this with a variable,
since changing the state of the switch may have to communicate with an
operating system written in some horrible language. The safest thing would
be a macro, whose expansion is system-dependent, and within the dynamic
extent of the macro's body unsolicited messages are controlled.
I'm not very optimistic about the possibility of standardizing on this kind
of environmental issue, but perhaps some very simple facility to prevent
messing up of the screen can be agreed on.
∂23-Apr-87 2150 Moon@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:50:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123691; Fri 24-Apr-87 00:49:23 EDT
Date: Fri, 24 Apr 87 00:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@sail.stanford.edu
cc: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
In-Reply-To: <870423123259.1.HORNIG@WINTER.SCRC.Symbolics.COM>
Message-ID: <870424004910.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here's an opinion on this issue from one of our developers, with an
interesting rationale. I agree with the rationale, which is why I
support either the mentioned proposal or the one that signals an error
and allows the outer THROW to be completed from the debugger.
Date: Thu, 23 Apr 87 12:32 EDT
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
I found KMP's proposal for this and I can now comment effectively. My
personal feelings are that the right proposal for 1 is the one below. I
agree with KMP that 2C is correct for 2.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1?):
Some may believe that the throw to BAR is suppressed,
the THROW to FOO should somehow complete, but that XXX would
never be printed.
The important factor here is that I believe that whenever there are two
THROW's in competition, that we should always proceed to the outermost
CATCH. This rule permits a programmer to assume that if he does a THROW
out of a computation that that computation will be exited, one way or
another. This is related to Moon's comment about the programming
environment and aborting.
∂23-Apr-87 2157 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:57:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123694; Fri 24-Apr-87 00:57:35 EDT
Date: Fri, 24 Apr 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870422165116.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870424005727.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
The wording of your proposal is such that it implies that implementations
that ignore the :ADJUSTABLE argument and simply make all arrays adjustable
would no longer be valid. I doubt that you intended this. Implementations
should not be required to implement the non-adjustability complexity if
they don't need it.
Your comment about dead arrays is too obscure.
Having ADJUST-ARRAY sometimes adjust the original array and sometimes
make a copy is dangerous. I suppose it's no more dangerous than
NREVERSE and SORT, but we know that programmers from all walks of life
consistently have trouble using NREVERSE and SORT correctly. I'd like
to see some thought given to improving the proposal to make it less
dangerous.
∂23-Apr-87 2209 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 22:09:05 PDT
Received: by navajo.stanford.edu; Thu, 23 Apr 87 21:08:20 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA25436; Thu, 23 Apr 87 20:39:17 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA06857; Thu, 23 Apr 87 21:36:52 PDT
Date: Thu, 23 Apr 87 21:36:52 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704240436.AA06857@bhopal.edsel.com>
To: navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu
In-Reply-To: Guy Steele's message of Thu, 23 Apr 87 17:33 EDT
Subject: AREF-1D
Your "clarifications" of 6-Dec-85 (distributed at the Boston Meeting
of what eventually became X3J13) added a function named ROW-MAJOR-AREF.
Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed
very natural and "called for". So Lucid Common Lisp has had it available
since shortly thereafter.
-- JonL --
∂23-Apr-87 2255 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 22:52:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123714; Fri 24-Apr-87 01:52:42 EDT
Date: Fri, 24 Apr 87 01:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-ID: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The reason for the name clash is that I wasn't looking at Steele's
corrections list at the time I generated the proposal. It was on an
independent list of Macsyma-related issues of my own. Sorry for the
confusion.
The fact that the row-major feature is built into more functions than
just those which have the phrase "ROW-MAJOR" in them (eg, displaced
arrays) leads me to believe that the phrase ROW-MAJOR is just redundant.
Also, I don't like the phrase "ROW-MAJOR" because it feels very 2d
because the term row seems to apply to 2d matrices. I know it's got a
perfectly well-defined way of generalizing, but...
Also, I thought a name with "1D" in it would emphasize that this was
a non-standard access. I guess "ROW-MAJOR" does that, too, though.
In any case, although I did have reasons for the choice of name, I'm
not passionate about them. Since there's already a precedent for the
other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.
By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
round out the set of operations which took an offset and either a list
of dimensions or an array and returned the standard reference pattern
might nicely round out the set of operations in this family...
∂24-Apr-87 1326 masinter.PA@Xerox.COM Re: Issue DEFVAR-INIT-TIME (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 13:26:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 APR 87 13:17:43 PDT
From: masinter.PA@Xerox.COM
Date: 24 Apr 87 13:17:31 PDT
Subject: Re: Issue DEFVAR-INIT-TIME (Version 1)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Thu, 23 Apr
87 16:59 EDT, <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870424-131743-2546@Xerox>
Kent,
Perhaps you could hold off submitting more issues until we get some of
the open ones out of the way?
∂24-Apr-87 1846 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87 18:46:54 PDT
Received: by navajo.stanford.edu; Fri, 24 Apr 87 17:46:11 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA29466; Fri, 24 Apr 87 17:09:51 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA07893; Fri, 24 Apr 87 18:07:26 PDT
Date: Fri, 24 Apr 87 18:07:26 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704250107.AA07893@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 24 Apr 87 00:57 EDT
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
The complexity of this discussion about adjust-array makes me wonder
if this function isn't striving for too much generality. Virtually all
usages I've seen or heard of are really for adjust-array-size. KMP's
proposal sounds like he's trying to avoid simply makeing a new array and
copying (after some fashion) the old into the new. Maybe it's a simpler
language design not to try to cover every possible base, but to provide the
primitives that permit end-users to "roll their own". In line with
your remarks:
Having ADJUST-ARRAY sometimes adjust the original array and sometimes
make a copy is dangerous. I suppose it's no more dangerous than
NREVERSE and SORT, but we know that programmers from all walks of life
consistently have trouble using NREVERSE and SORT correctly. I'd like
to see some thought given to improving the proposal to make it less
dangerous.
How about the following simplification for adjust-array:
(1) a new function shall be added which will copy parts of the contents
of one array into another; MacLisp's FILLARRAY is a base-level start
for such a function, but one would like something for multi-dimensional
arrays that is more meaningful than simple linear, row-wise fill.
(2) adjust array will only "mess" with the size (or dimensions) and with
the displacement (i.e., to a new target array, or new index-offset).
Fill-pointers can already be modified with setf. Getting new contents
into a displaced, "adjusted" array can be done by first calling the
function ARRAY-DISPLACED-P (as specified in GLS's "clarifications" of
6-Dec-85) and then using the function called for in (1) to copy parts
of the original displaced-to array into the newly-displaced one.
-- JonL --
∂25-Apr-87 0021 gls@think.com DELETE, SORT, ADJUST-ARRAY considered harmful
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Apr 87 00:21:31 PDT
Received: by Think.COM; Sat, 25 Apr 87 02:25:34 EST
Date: Sat, 25 Apr 87 02:25:34 EST
From: Guy Steele <gls@think.com>
Message-Id: <8704250725.AA21198@Think.COM>
To: cl-cleanup@sail.stanford.edu
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful
Here is an idea that is only two-thirds whimsical: since 90% of all
people who use DELETE, SORT, etc. lose because they fail to put a setq
around it (as in (SETQ X (DELETE ITEM X)), etc.), why not make it
impossible for them to lose? Remove these primitives from the language,
and introduce their inverses as SETF places. For example, instead of
writing (SORT BREAKFAST) or (SETF X (SORT BREAKFAST)), write
(SETF (SCRAMBLE X) BREAKFAST)
; that is, the variable X is changed so as to make the value of
BREAKFAST a scrambled version of it. SCRAMBLE would not be a function
itself; you could use it only within a SETF, thereby guaranteeing you
don't lose. Similarly (SETF (UNDELETE ITEM Z) Z),
(SETF (UNADJUST-ARRAY Z) Z), and so on.
Well, maybe the proposed syntax stinks, but perhaps some way of
idiot-proofing destructive operations should nevertheless be found.
--Yours for a safer language,
Quux
P.S. I thought you'd never ask: haven't you ever had
scrambled X for breakfast?
∂27-Apr-87 1151 Masinter.pa@Xerox.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87 11:51:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 11:43:07 PDT
Date: 27 Apr 87 11:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 23 Apr 87 17:50 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870427-114307-1095@Xerox>
How does this (new) proposal relate to the (old) proposal by Touretsky?
I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
while going ahead with a separate proposal which seems to relate to
similar concerns.
Comments?
∂27-Apr-87 1312 Masinter.pa@Xerox.COM status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:12:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 13:07:08 PDT
Date: 27 Apr 87 13:15 PDT
From: Masinter.pa@Xerox.COM
Subject: status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870427-130708-1239@Xerox>
This is my status file. Please mail any corrections you have.
I don't think we've made very good progress. The only issue that I've
seen resolution on since our meeting before X3J13 is
FLET-IMPLICIT-BLOCK.
I think we can re-release COMPILER-WARNING-STREAM ( Version 3),
DEFVAR-INITIALIZATION (Version 3), FORMAT-ATSIGN-COLON (Revision 3),
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
I think we are near completion on these, but they need writing work
*SOON*:
DEFVAR-INIT-TIME, DO-SYMBOLS-DUPLICATES (Revision 1),
GET-SETF-METHOD-ENVIRONMENT, FORMAT-OP-C (revision 1), FUNCTION-TYPE
(revision 2), IF-BODY (Version 4), KEYWORD-ARGUMENT-NAME-PACKAGE
(Version 1), PRINC-CHARACTER:WRITE-CHAR
The rest seem further from general agreement of the form of the
proposal.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ADJUST-ARRAY-NOT-ADJUSTABLE
Submitted by KMP 22-Apr-87
comment from Moon, JonL 24-Apr
ADJUST-ARRAY-DISPLACEMENT (revision 1)
Revision 1 by SEF, 18-Apr-87
Comment by Moon 21 Apr 87
AREF-1D
Submitted 22-Apr-87 by KMP
Discussion about name of function, addition of ROW-MAJOR-INDEX
function, etc.
ROW-MAJOR-AREF in clarifications
ASSOC-RASSOC-IF-KEY
Submitted 22-Apr-87 by KMP
COMPILER-WARNING-BREAK (revision 2)
not Released.
Questions on interaction with condition proposal.
remailed 7-apr-87
SEF suggested KMP should work on.
COMPILER-WARNING-STREAM (Revision 4)
Rev 3 was released
Version 4, submittted by SEF
Decided to revert to previous version,
consider DRIBBLE as a separate item.
Need to add DRIBBLE note in Discussion.
DEFVAR-INITIALIZATION (Revision 3)
Released
remailed 7-apr-87
(final form)
DEFVAR-INIT-TIME
Submitted 23-Apr-87, Version 1 by Pitman
DO-SYMBOLS-DUPLICATES (Revision 1)
mailed 7-apr-87
Revision 1 by SEF 17-apr
Not released, in discussion
Questions "is it really inefficient to require non-duplicates?" Add
more arguments?
ENVIRONMENT-ARGUMENTS (revision 1)
SEF summarized issues 18-Apr
Decided to separate again and:
Approve GET-SETF-METHOD-ENVIRONMENT
drop MACRO-FUNCTION-ENVIRONMENT
("merely adding an optional argument to macro-function is not
enough")
discuss SPECIAL-FORM-SHADOW
FLET-IMPLICIT-BLOCK (Revision 5)
Discussion & agreement on cl-cleanup.
revision by Fahlman, 17-Apr-87 to cl-cleanup
FORMAT-ATSIGN-COLON (Revision 3)
Released.
(final form, mailed 17-Apr-87)
FORMAT-OP-C (revision 1)
Discussed and agreed, final form not yet available
(with Moon's amendment)
Need volunteer.
FUNCTION-TYPE (revision 2)
General agreement on basic proposal.
Wording to be worked out.
Mailed 17-Apr-87
Fahlman volunteered to revise & run by RPG
GC-MESSAGES (version 1)
Submitted by Pitman 23-Apr-87
Discussion "a little short-sighted"?
IF-BODY (Version 4)
General agreement to recommend against.
Final form not yet available.
Version 4 mailed by KMP , 19-Apr-87
KMP to produce a new version which Scott will think is balanced
IGNORE-ERRORS
Discussed and agreed, final form not yet available
(LMM: Some objections, defer to error/signal committee?)
Need volunteer.
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
Released
Should remove confusing "To further clarify: " which is
about INTERN and not IMPORT.
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 1)
Submitted by Moon 20 Apr 87.
Discussion: justification with examples or reference needed before
releasing to X3J13
"I'm sure you've got a good reason for proposing this,
and I'd like some indication of what it is."
PEEK-CHAR-READ-CHAR-ECHO
Agreed to be controversial
Need volunteer to summarize positions.
PRINC-CHARACTER:WRITE-CHAR
Discussed and agreed, final form not yet available
(write-char choice)
Need volunteer.
PROMPT-FOR
Agreed to be controversial
Need volunteer to summarize positions.
REMF-DESTURCTION-UNSPECIFIED
Not discussed
Need volunteer to check over, lead discussion.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Tabled, a subset which deals with only those functions that
don't work in positions will be separated out.
Need volunteer.
SHARPSIGN-BACKSLASH-BITS
No general agreement (the meeting notes read "we cringed")
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-PACKAGE
Discussed, without general agremenet.
Need volunteer to summarize positions.
TAILP-NIL
Received but not discussed
Need volunteer to lead discussion, summarize positions.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Discussed and agreed at meeting, final form not yet available
Moon forwards Hornig msg pointing some problems 23-Apr-87
∂28-Apr-87 1114 KMP@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87 11:13:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126277; Tue 28-Apr-87 14:13:26 EDT
Date: Tue, 28 Apr 87 14:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <12276526020.28.TOURETZKY@C.CS.CMU.EDU>,
<870315-164404-1975@Xerox>
Message-ID: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
Status: For Internal Discussion
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Notes about Voting:
Select one of:
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED (by Pitman)
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED (status quo)
[See also notes in the discussion about the possibility of a fourth
way to go if you're not satisfied with any of these.]
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on arbitrary arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Modify the definition of MAKE-SEQUENCE to accept array descriptions as
well as vector descriptions.
Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays.
These functions should treat array arguments as vectors displaced to the
array storage (in row-major format). The affected functions are LENGTH,
ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, NSUBSTITUTE, NREVERSE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42,
and (ELT A 7) should return A[0,1,0]. :START and :END keywords would
be interpreted relative to the vector, as would the results returned
by POSITION and SEARCH.
Extend the definitions of sequence functions whose result should be the
same shape as but not necessarily EQ to some argument. These functions
should deal with array arguments by returning an array of the same
shape. The affected functions are SUBSTITUTE, REVERSE, and MAP.
Expressly forbid arrays as arguments to sequence functions that modify
the number of elements in the array because the shape would be undefined.
These functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE,
REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a
sequence function, and it already has a well-defined behavior for arrays.
To test whether the arrays A and B, of different shapes, have the same
elements, one would write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, REDUCE, etc., or else they can build displaced vectors by
hand and pass them to the sequence functions when necessary.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Note that simply extending COERCE, MAKE-SEQUENCE, LENGTH, ELT, and
the SETF expander for ELT would have the side effect of extending
the remaining functions if they are written in the obvious way.
For example:
(DEFUN SUBSTITUTE (NEW-ITEM OLD-ITEM SEQUENCE &KEY ...)
(LET ((RESULT (MAKE-SEQUENCE (TYPE-OF SEQUENCE))))
(DOTIMES (I (LENGTH SEQUENCE) RESULT)
(SETF (ELT RESULT I)
(IF (EQL (ELT SEQUENCE I) OLD-ITEM)
NEW-ITEM
(ELT SEQUENCE I))))))
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly
avoiding the temptation to turn Common Lisp into a half-baked APL.
Instead of trying to provide a full set of array handling primitives
(which would be needed to take arbitrary k-dimensional slices out of
n-dimensional arrays, or to apply an operator across a specific
dimension of a multidimensional array), it requires just one rule:
treat arrays as displaced vectors.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on certain arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Extend the definitions of sequence functions that either return their
argument sequences, return sequences which are the same shape as their
argument, or return non-sequences so that they also allow arrays iff
their action is conceptually independent of the shape of the array.
The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions. These
unaffected functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, etc., or else they can build displaced vectors by hand and
pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting
ways without committing us to a theory of how arrays and sequences
relate that everyone may not be happy with right now.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This extends certain existing sequence functions to allow arrays
as arguments in a fairly non-controversial way, leaving aside the
larger issue of whether and how to generalize the other sequence
functions.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED):
This is the null proposal for the sake of voting clarity. Vote for this
if you think things should not change.
Current Practice:
Neither SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE nor
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED are likely to be implemented
anywhere since they are only very recently proposed.
Discussion:
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE.
He's been building displaced vectors to pass to sequence functions when
necessary and really dislikes it.
The members of the Cleanup committee expressed interest in the ideas
behind this proposal but weren't sure they could accept it in the
proposed form. A rewrite to separate some of the issues more clearly
was solicited.
Rees suggested that if people are not sure about this a proposal, it might
be possible to make fly a modified version of the proposal which extended
only those functions which did not deal with positional information.
Pitman wrote SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED based on this idea
and supports at least that much extension, and is sympathetic to (but not
yet fully committed to the idea of the full proposal).
Note that in the SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED proposal,
the function REDUCE is in a grey area. Many of its uses are not
position-dependent, but some are. The same argument might be made about
FIND. If people felt strongly, these too could be extended either by
fudging the conservative rule or by explicit special case(s).
[It's also possible that a still-more-general proposal might be
interesting. For example, one that introduced and inverse to
ARRAY-ROW-MAJOR-INDEX called ARROW-ROW-MAJOR-SUBSCRIPTS, and have
functions like POSITION that returned position information or things
that take :START and :END arguments use subscript (rather than offset)
information. eg,
(SETQ A (MAKE-ARRAY '(2 2) :INITIAL-ELEMENT 0))
(SETF (AREF A 1 0) '1)
(POSITION 1 A) => (1 0) ;Rather than 2 as suggested above
This might ease some people's minds if they're just worried that
returning a 1-d index will feel funny for an any-d array. On the
other hand, the linear ordering must still be well defined so it'll
be clear what the search order is, what range is being selected when
:START and/or :END is used, etc. so you can't hide the issue
completely. Still, if anyone's interested in a full-blown proposal
along these lines, they should ask me and I'll write it. --KMP]
∂28-Apr-87 1334 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Apr 87 13:34:01 PDT
Date: Tue, 28 Apr 87 16:35:56 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU
Message-ID: <192342.870428.JAR@AI.AI.MIT.EDU>
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ENHANCEMENT
Edit history: Revision 2 by JAR 04/28/87
Status: Very preliminary.
Description of problem:
CLtL pp. 55-56 implies that if a name (symbol) is not proclaimed or
declared special, then a free reference to that name is a reference to
the special variable of that name, while a LAMBDA-binding of that name
indicates a binding of the lexical variable of that name. This would
mean that the following program is legal and that (TST) => 4:
(defun tst ()
(setq x 3)
(funcall (let ((x 4)) #'(lambda () x))))
However, if you feed this program to many Common Lisp compilers
(including Symbolics's and DEC's), a warning message will be
produced for the SETQ, saying something like "Warning: X not
declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so
prominently that a user would be hard put to say that a program
which elicited such warning messages was "correct" in that
implementation. Unlike the situation with unused variables, there is
no possible declaration one can write which suppresses the warning
messages.
This disagreement between theory and practice should be mended
somehow.
Proposal (PROCLAIM-LEXICAL:CURRENT-PRACTICE):
Change the language definition (page 55?) to say that it is an error
for there to be a free reference or assignment to a name unless a
SPECIAL proclamation or declaration is in effect for that name.
This would legitimize the behavior of current implementations.
Proposal (PROCLAIM-LEXICAL:BY-THE-BOOK):
Shame implementors into going by the book. Implementations should
simply stop intimidating users who want to write code like this.
"Apparently unbound variable" warnings should be given the same
purely advisory status that "apparently undefined function" warnings
now enjoy. The exact meaning of this is of course implementation-
dependent.
Proposal (PROCLAIM-LEXICAL:GENERAL):
Introduce a new declaration specifier, LEXICAL, which is dual to the
SPECIAL declaration specifier; it may appear in proclamations and
declarations.
A name may be proclaimed either lexical or special, but not both.
A free reference or assignment to a name is an error if there is
neither a SPECIAL nor a LEXICAL proclamation or declaration in
effect for the name. A LAMBDA-binding in the absence of a
declaration or proclamation binds the lexical variable.
The global lexical environment and the global dynamic environment
are identical. I.e. an assignment to the global binding of a
lexical variable will be reflected in the observed global value of
the dynamic variable of the same name, and vice versa.
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
Proposal (PROCLAIM-LEXICAL:RESTRICTED):
Same as PROCLAIM-LEXICAL:GENERAL, but with the following restriction:
If a name is proclaimed lexical, then it is an error for there to be
a special declaration of the same name. For example, the special
declaration of X in the example is an error.
Cost of adopting change:
CURRENT-PRACTICE: Ostensibly none, although implementations which
don't signal this as an error should be explicitly encouraged
to do so. It ought to be signalled in interpreted code as well.
BY-THE-BOOK: This would be an easy fix to the error reporting and
bookkeepping components of existing compilers. Of course it is not
a change to the language, so there is no impact on portable code.
GENERAL: This would be straightforward to implement, and is perhaps even
already present, in implementations that use deep binding for
special variables. In shallow bound implementations there's a
problem because two "global" value cells are needed: one for the
current dynamic binding, and one for the global lexical binding;
and when no dynamic binding is in effect, they must somehow be
"coalesced" so that SETQ's are reflected in both.
RESTRICTED: This is specifically designed to address the
implementation problems of GENERAL. Having a dynamic binding and
having a global lexical binding are mutually exclusive.
Benefits:
CURRENT-PRACTICE is incompatible with Scheme, which explicitly
allows a program to have both a global binding and LAMBDA bindings
of the same variable. Therefore, adopting any of the other three
proposals would be a major step towards reducing the
incompatibilities between the two languages, since both code
conversion and embedded scheme implementations would be made easier
and more graceful.
GENERAL and RESTRICTED have the additional advantage that, in an
implementation that uses deep binding for dynamic variables, a
lexical proclamation can be used to achieve significant performance
gains on references and assignments to global variables. A LEXICAL
proclamation would also allow some desirable redundancy, both
for documentation and for error checking.
Cost of converting existing code:
CURRENT-PRACTICE: Some programs may rely on the CLtL semantics;
these would have to be changed if what they're doing now becomes
officially erroneous. People might find consistent enforcement
of this rule rather surprising and frustrating.
GENERAL and RESTRICTED are both upwards compatible. Of course,
code-walking utilities would have to be taught about the new
feature, since it affects the basic semantics of the language.
Aesthetics:
The special/lexical business is generally one of CL's most insidious
and disgusting aspects, and really needs a much more thorough
overhaul than is proposed above (e.g. there ought to be a separate
DYNAMIC-LET or SPECIAL-LET which does dynamic binding). But this is
probably practically and politically infeasible. Given that, I
don't think any of these proposals has clear advantages or
disadvantages from the point of view of simplicity or elegance of
description, except that GENERAL is somewhat easier to describe
than RESTRICTED.
Discussion:
The four proposals indicate the range of possibilities. After some
discussion, we ought to be able to prune this down, of course.
JAR thinks that CURRENT-PRACTICE is unacceptable, BY-THE-BOOK is
unsatisfying but somewhat better, and GENERAL has unsolved implementation
problems, even though it seems the most powerful, symmetric, and elegant.
Thus RESTRICTED seems preferable.
This proposal ignores the question of what to do about an analogue
of DEFVAR or DEFPARAMETER for global lexicals. Interlisp and PSL both
have something along these lines (DEFGLOBAL), don't they?
Given the presence of lexical proclamations in the language, it's
still not clear whether a free, undeclared, unproclaimed reference
should be an error, and if it's not an error, whether it should refer
to the lexical binding or the special binding. I suggest that it not
be an error, and I don't really care what its meaning should be (since
in the situation I care about I'm not going to be dynamically binding
the variable anyhow, so it doesn't matter). The RESTRICTED semantics
would imply that such a reference would have to be to the special
variable.
[By the way, I don't like this use of the term "variable," but I'm
trying to be consistent with CLtL p. 55. Note that according to this
it doesn't make any sense to talk about "declaring a variable to be
special" since any variable is already either special or lexical; it
is names which can be so declared. The book is definitely NOT
consistent about this, and ought to be fixed.]
∂28-Apr-87 1916 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87 19:16:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126601; Tue 28-Apr-87 18:52:26 EDT
Date: Tue, 28 Apr 87 18:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, JAR@AI.AI.MIT.EDU
Message-ID: <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support PROCLAIM-LEXICAL:GENERAL if the implementation issues can
be worked out, which I think they can.
I spoke with Jonathan briefly about these problems and I think he
agrees with me that they're not really a problem if you just keep
the global lexical value cells someplace other than the SYMBOL-VALUE
of the symbol.
For example, you might write:
(DEFVAR SYSTEM:*THE-GLOBAL-LEXICAL-VALUE-CELLS* (MAKE-HASH-TABLE))
(DEFUN SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (SYMBOL)
(OR (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
(SETF (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
(CONS SYMBOL ;For debugging
SYSTEM:*UNBOUND-MARKER*))))
(DEFMACRO SYSTEM:GLOBAL-LEXICAL-VALUE (SYMBOL)
`(CDR (EVALUATE-AT-LOAD-TIME (SYSTEM:GLOBAL-LEXICAL-VALUE-CELL ',SYMBOL))))
Of course (as stated above), this changes his proposal slightly to
make the global lexical and dynamic environments disjoint. That is,
programs like
(DEFUN MAYBE-EVEN-BUT-SURELY-ODD ()
(+ (LOCALLY (DECLARE (LEXICAL X) (INTEGER X)) X)
(LOCALLY (DECLARE (SPECIAL X) (INTEGER X)) X)))
could return odd numbers (since lexical X and special X might denote
different quantities).
The contract of the compiler would be to turn global lexical
references to a symbol into (SYSTEM:GLOBAL-LEXICAL-VALUE 'symbol).
The call to SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (ie, the GETHASH) need
happen only once (at load time) so its speed is not important.
If the above code wanted to be portable, of course, you'd have to have
an S-expression equivalent to #, called EVALUATE-AT-LOAD-TIME. Most
implementations have such a thing, I think, they just don't let it out
for users to play with. In fact, I think CL should have such a thing
since this isn't the first case where people have wanted it.
In any case, portability isn't relevant to this message since all
that's needed is to demonstrate that it would be feasible to implement
this in all systems, which I think the above code demonstrates.
∂28-Apr-87 2204 masinter.PA@Xerox.COM Re: Issue: PROCLAIM-LEXICAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Apr 87 22:04:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 22:04:03 PDT
From: masinter.PA@Xerox.COM
Date: 28 Apr 87 22:02:51 PDT
Subject: Re: Issue: PROCLAIM-LEXICAL
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Tue, 28 Apr
87 18:52 EDT, <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
Message-ID: <870428-220403-2039@Xerox>
Jonathan left out the alternative that I thought most natural, namely
that otherwise undeclared
variables were not an error, but would default lexical. E.g.,
(setq x 3)
(defun frob () (incf x))
would not be an error, but would always refer to the lexically global x.
This would bring variable scoping in line with function scoping when
there were no declarations. (A state of grace.)
I presume that Kent didn't really mean to propose that the global
lexical environment be different from the global dynamic environment,
but that was just an awkward artifact of his sample implementation.
Right Kent?
The only idiom which might have portability problems are dynamic calls
to EVAL that get the dynamic binding, e.g., instead of using
SYMBOL-VALUE, e.g., user has a data base of permutations of variables &
values, and also of expressions, binds the variables with PROGV and then
evaluates the expressions.
While current practice is that compilers will warn about undeclared free
references, I know of no interpreter that does, do you?
∂29-Apr-87 0641 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 06:35:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126932; Wed 29-Apr-87 09:35:59 EDT
Date: Wed, 29 Apr 87 09:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PROCLAIM-LEXICAL
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
JAR@AI.AI.MIT.EDU
In-Reply-To: <870428-220403-2039@Xerox>
Message-ID: <870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm sympathetic to the idea that undeclared free variables should
default lexical. Certainly if we had lexical globals I'd expect that
some compilers would start defaulting free variables lexical while
others would continue to default them special, so perhaps we should
just go ahead and make it well-defined.
Anyway, the separation of global lexical environment from global special
environment seems to me important. After all, you can already do:
(DEFUN F (X) (+ X (LOCALLY (DECLARE (SPECIAL X)) X)))
and see two different variables X without any intervening rebinding.
I was just assuring that this effect was properly carried through.
Also, this assures that people cannot muck with the lexical binding
of any variable. Special variables are kind of 3lispy in nature because
we're told how they're represented and we have primitives for manipulating
them either as variables or as data. I think this makes program proofs
more difficult. The feature of lexical variables is that all of their
uses are statically detectable; this would not be so for global lexicals
if their homes were something that users were permitted to read in a
non-statically-detectable way (eg, using SYMBOL-VALUE) or set (using SETF
of same). By making the lexical bindings totally isolated, you ensure
the right of the compiler to do much better compilation of global lexicals
in some cases than it might be able to do for global specials, and at the
same time you don't make any unpleasant changes to the mechanisms already
in place and in use for specials.
And finally, if you separate the two spaces, then you can go back and
forth between declaring variables special or not without it having strange
effect on things already compiled. eg, if you needed:
(DEFGLOBAL Y 3)
(DEFUN F (X) (+ X Y))
...
(PROCLAIM '(SPECIAL Y))
(DEFUN FOO (Y) (BAR))
(DEFUN BAR () ... (SETQ Y ...) ...)
(PROCLAIM '(LEXICAL Y))
without worrying that the global lexical Y=3 binding was in danger
of getting modified (which it seems intuitive to me that it should
not have been).
MACSYMA, for example, needs an UNSPECIAL declaration because on a
per-file basis it goes back and forth between using the same name either
special or lexical. Alternating back and forth between default LEXICAL
and default SPECIAL would serve it as well if we made that legal.
If such alternation meant that programs previously compiled using the
other semantics were now in error or might behave differently than I
intended at time-of-definition, then you've defeated the purpose of my
doing the alternation. I think the separation of namespaces ensures
intuitive behavior.
∂29-Apr-87 0938 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 09:38:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127175; Wed 29-Apr-87 12:38:42 EDT
Date: Wed, 29 Apr 87 12:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (merge Moon's suggestion)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should
be culturally compatible with the host environment." This description
is not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose
that wasn't planned on:
(FORMAT NIL "~C" #\Space) might "Space" rather than " ".
[Anyone who would argue that the word `abbreviated' in the definition
was supposed to prevent this should just be happy that some implementors
didn't choose to interpret that word to mean that "Sp" should come back.]
Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and
~:C equivalently or very similarly, which seems like a waste of a FORMAT op.
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; FORMAT does not suffice (unless you use
~Q of #'WRITE-CHAR -- which is generally neither pretty nor convenient).
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the description of ~C on p389 to say:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Add the following to the description of WRITE-CHAR on p384:
Note: The glyphs used to present characters which are not in
the standard character set may vary from implementation to
implementation or output device to output device. WRITE-CHAR
will always output a single character to the indicated stream.
On some streams, super-quoting, character substitution, or
substitution of a string for a single character may be
necessary; it is appropriate for the stream to decide to do
this, but WRITE-CHAR itself will never do this.
Rationale:
This was probably the intent of the authors.
It makes things clear enough that programmers can know what to
expect in the normal case (standard characters with zero bits)
while leaving some flexibility to implementors about what to do in
the case of bits (which are not particularly well-defined across
different implementations anyway).
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would suffer an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable.
As things stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of
"~C" and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as
a simplification.
Discussion:
Pitman thinks it's important to get this cleared up as soon as possible.
Moon's comment on Version 1 (which tried to make WRITE-CHAR and ~C
identical in all cases) was:
I believe the error in CLtL is that it was not stated explicitly
that the "implementation-dependent abbreviated format" applies only
to characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as write-char for characters
with zero char-bits. I don't think we want to require ~C and
write-char to do the same thing for characters with bits.
Steele and Fahlman seemed to like the idea of the proposal if amended
as Moon suggested. Pitman did the merge, creating Version 2. If he didn't
blow it somehow, they should now be happy.
∂29-Apr-87 0943 KMP@STONY-BROOK.SCRC.Symbolics.COM status of DEFVAR-INIT-TIME
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 09:43:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127180; Wed 29-Apr-87 12:43:47 EDT
Date: Wed, 29 Apr 87 12:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: status of DEFVAR-INIT-TIME
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <870427-130708-1239@Xerox>
Message-ID: <870429124341.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 Apr 87 13:15 PDT
From: Masinter.pa@Xerox.COM
This is my status file. Please mail any corrections you have.
...
I think we are near completion on these, but they need writing work
*SOON*:
DEFVAR-INIT-TIME, ...
I saw no reply at all to DEFVAR-INIT-TIME (other than your mail saying
to please hold off on new proposals until the ones we have get cleaned up).
In the absence of any comments on what might be wrong with this proposal
(which I personally think is pretty non-controversial), I'm not able to
produce an update. If anyone has objections (or just wants to second it
as-is), they should voice them.
∂29-Apr-87 1024 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 10:24:34 PDT
Date: Wed, 29 Apr 87 13:26:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: masinter.PA@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of 28 Apr 87 22:02:51 PDT from masinter.PA at Xerox.COM
Message-ID: <192793.870429.JAR@AI.AI.MIT.EDU>
Date: 28 Apr 87 22:02:51 PDT
From: masinter.PA at Xerox.COM
While current practice is that compilers will warn about undeclared free
references, I know of no interpreter that does, do you?
The VAX LISP interpreter will generate such warnings if an internal,
unreleased switch is set non-nil. Its default value is nil. For a week
or two when the feature first appeared (only inside DEC, of course) the
switch was defaultly true. Some people liked the immediate feedback,
but overall the warnings were judged too radical and disconcerting, so
the default was changed.
∂29-Apr-87 1025 KMP@STONY-BROOK.SCRC.Symbolics.COM Procedure for Steele's proposed clarifications
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 10:25:44 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127203; Wed 29-Apr-87 13:08:07 EDT
Date: Wed, 29 Apr 87 13:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Procedure for Steele's proposed clarifications
To: Masinter.PA@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
References: <870427-130708-1239@Xerox>
Message-ID: <870429130801.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
If something is in Steele's clarifications (X3J13/86-003), do we
still need to write it up in full blown form for vote?
In particular, does the fact that my AREF-1D proposal overlaps
with the proposal for ROW-MAJOR-AREF mean that I should modify
my proposal to use the new name (which I'm certainly content to
do) or that I should retract my proposal since the same proposal
is already on the floor.
I certainly think that full-blown forms of all the things in
the clarifications would be nice because it would save a lot of
time at meetings answering obvious questions, but some of the
things in that document are pretty simple and straightforward
in their one-liner form and I just want to clarify before doing
a lot of work that expanding them is what is intended.
∂29-Apr-87 1131 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 11:30:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127310; Wed 29-Apr-87 14:18:24 EDT
Date: Wed, 29 Apr 87 14:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
In-Reply-To: <870427-114307-1095@Xerox>
Message-ID: <870429141817.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 Apr 87 11:51 PDT
From: Masinter.pa@Xerox.COM
Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
How does this (new) proposal relate to the (old) proposal by Touretsky?
[For Touretzky's context, the "new" proposal being referred to was one to
introduce a function AREF-1D (later renamed to ROW-MAJOR-AREF to correspond
to a name chosen earlier by Steele in a suggested clarifications document
he distributed).]
I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
while going ahead with a separate proposal which seems to relate to
similar concerns.
Comments?
At first I wondered if the omission of a proposal to generalize AREF so
that if you gave it a single index it (implicitly asserting it to be a
vector, and hence a sequence), then it should just do a 1-d AREF (as ELT
would do). In fact, however, I think this would decrease error checking
in an undesirable way and my guess is that Touretzky was being very
deliberate in not including a proposal to do this.
Moreover, although some compilers might treat
(ELT (THE ARRAY X) 3)
as efficiently as
(ROW-MAJOR-AREF X 3)
I don't think anyone would be willing to require such efficient treatment.
In compilers which didn't optimize this (and in most interpreters, too)
you'd still have to do the LISTP check before getting around to the
implicit ROW-MAJOR-AREF. Although it isn't suggested that ROW-MAJOR-AREF
is needed only for efficiency, it is true that most applications where it's
likely to be used need maximal efficiency, so I think making it a separate
primitive is appropriate.
All this being said, I think it's safe to make these two proposals proceed
in parallel without worrying that they conflict in some way. If you're not
convinced, please let me know.
∂29-Apr-87 1234 Pavel.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 12:34:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 11:53:00 PDT
Date: 29 Apr 87 11:52 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-115300-2626@Xerox>
The mention of the non-standard format directive ~Q should be removed
from the proposal. Other than that, I favor it.
Pavel
∂29-Apr-87 1246 KMP@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 12:46:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127412; Wed 29-Apr-87 15:46:19 EDT
Date: Wed, 29 Apr 87 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I removed the FORMAT-OP-C proposal from this since no one seemed to be
championing it. As far as I know, this was the only simplification anyone
had asked for. -kmp
========================================================================
Issue: PRINC-CHARACTER
References: PRINC (p383)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* For (FORMAT NIL "Foo~ABar" #\Space)
Pretty result: "Foo Bar"
Ugly result: "FooSpaceBar"
In other words, " " looks better here.
* For (FORMAT T "Type ~C to continue" #\Space)
Pretty result: "Type Space to continue"
Ugly result: "Type to continue"
In other words, "Space" looks better here.
Proposal (PRINC-CHARACTER:WRITE-CHAR):
(PRINC char stream) should be defined to be equivalent to
(WRITE-CHAR char stream).
Rationale:
The behavior of (PRINC char) should be well-defined even if a
completely arbitrary decision had to be made.
In fact, though, we can get some advice by appealing to history.
The only data type which corresponds to characters in most old
lisps was symbols. For example, in Maclisp,
(PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))
In Common Lisp, it would make sense in the absence of arguments
to the contrary to preserve an analagous relation, namely:
(PRINC char) == (WRITE-CHAR char)
Current Practice:
Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
"Space" for (PRINC #\Space).
Symbolics and Spice are known to use the WRITE-CHAR strategy.
Vaxlisp and Lucid might be using it, too, or they might be
using ~C in FORMAT; no one familiar with their internals has
commented.
In any case, some other implementations are believed to differ
(ie, to output "Space" when you PRINC a #\Space), but a specific
reference is not currently available. In any case, the wording
in CLtL is not clear enough to preclude such a differing
implementation from `legitimately' emerging.
Adoption Cost:
Any implementations which did not already implement this proposal
decided upon would suffer an incompatible change.
Benefits:
User code that uses PRINC (and presumably ~A) on characters would
have a chance of being portable.
Conversion Cost:
It's easy to search for occurrences of PRINC and ~A in code, but
it may not always be apparent when the argument is a character.
Automatic conversion is unlikely to succeed.
Aesthetics:
Making PRINC do something well-defined for as many primitive data
types as possible will probably be perceived as a simplification.
Discussion:
KMP thinks this is moderately important because it is embarrassing
to have commonly used functions like this vary so widely in behavior
between implementations. He doesn't think it is critical because
(if nothing else) it is only one of many problems with the vague
contract of PRINC.
There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
suggested making PRINC work like ~C in FORMAT, but no one seemed
to think that was useful and the proposal was removed for Version 2
to keep from muddying what's likely to be a very straightforward
vote in favor of PRINC-CHARACTER:WRITE-CHAR.
∂29-Apr-87 1337 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 13:37:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127499; Wed 29-Apr-87 16:37:14 EDT
Date: Wed, 29 Apr 87 16:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870427182129.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
Message-ID: <870429163704.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I hope this draft manages to merge the IF-BODY:NO stuff in
a relatively fair way. -kmp
``... looks reasonably balanced to me, and represents my
own opinions adequately. I see no objection to releasing
it to the world at large ...''
-- Guy L. Steele, Jr.
author of ``Common Lisp: The Language''
==============================================================================
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history: 27-Feb-87, Version 1 by Pitman (IF-BODY:YES)
3-Mar-87, Version 2 by Fahlman (added IF-BODY:NO)
17-Apr-87, Version 3 by Masinter (merged v1 and v2)
19-Apr-87, Version 4 by Pitman (misc editing to v3)
27-Apr-87, Version 5 by Pitman (reworked for balance)
Status: Not for release
Problem Description:
CLtL defines the meaning of an IF expression only in the case of two or
three arguments. Some implementations extend the meaning to allow more
arguments.
Typically, using the extended IF syntax will not generate a warning in
environments which support it. Code developed where these features are
available is not typically discovered to be in error until a port to
some other implementation is attempted. At that point, which is
typically inconveniently late in the development cycle, the developer
may notice that code either does not compile (generates syntax errors)
or does not compile correctly (the additional forms are quietly ignored
and the code generated is not what the writer intended).
The problem is rightly due to the user, but users typically expect that
they should be warned about such problems. Unfortunately, however, both
the Lisp which allows the extended syntax and that which fails to signal
an error about the invalid syntax are within their rights as currently
stated.
This phenomenon is a barrier to Common Lisp's portability goals.
Test Case:
(IF NIL 'THEN 'ELSE 'MORE)
According to CLtL, this is an error.
In some implementations, this returns ELSE.
In some implementations, this returns MORE.
In some implementations, this signals an error at syntax analysis time.
Notes about Voting:
Select one of IF-BODY:ILLEGAL, IF-BODY:LEGAL, or IF-BODY:UNCHANGED.
Proposal (IF-BODY:ILLEGAL):
Restrict IF, making it expressly illegal to supply more than three
argument forms. Require that implementations signal an error at
syntax analysis time.
Rationale:
As long as some implementations provide this extension while
others do not, the portability goals of Common Lisp will suffer.
It is not adequate to encourage implementors to warn about
non-standard uses since the only implementations which will
implement the extension are ones who think it is a good idea to
use the feature, and people are not inclined to warn about things
they think are a good idea to use.
Although some implementations offer extended definitions and
this would be an incompatible change, the cost of that change
would be offset by the improvement in code portability.
Adoption Cost:
The direct act of making this restriction is trivial, but there
are nth order effects which may be non-trivial...
In Symbolics implementations the SCL package contains Symbolics'
extensions to LISP. Currently, for any symbol LISP:xxx, the
expression (EQ 'LISP:xxx 'SCL:xxx) => T. This change would force
as a second order effect a decision about whether to make
(EQ 'LISP:IF 'SCL:IF) => NIL or to rewrite all code (user and
system) using the extended IF.
Since there are currently no cases where LISP symbols are not
shared by SCL, a decision to break the sharing would force us
to do a complicated re-evaluate our position on the nature of
compatibility between Common Lisp and the extensions we provide.
The cost of this option is therefore potentially large.
Conversion Cost:
Uses of IF in correct Common Lisp code are technically unaffected
by this change, although it should be clear from the discussion
of Adoption Cost that viewing things this way may be just a word
game. In practice, there might be non-trivial effects on
code that is not technically `Common Lisp' but which is thought to
be `Common Lisp compatible.' The importance of this must be weighed
in context, but should not be discounted altogether.
Benefits:
Code portability between certain dialects would be improved.
Aesthetics:
The (IF test then else) syntax is neatly symmetric and this
symmetry should be preserved.
Some people find the asymmetry of the (IF test then {else}*)
syntax to be visually confusing.
IF is supposed to be the simplest conditional form, from which
all the others are built.
Proposal (IF-BODY:LEGAL):
Extend IF, making it expressly legal to supply an implicit-PROGN of
`else' forms using the syntax (IF test then {else}*).
Rationale:
As long as some implementations provide this extension while
others do not, the portability goals of Common Lisp will suffer.
It is not adequate to encourage implementors to warn about
non-standard uses since the only implementations which will
implement the extension are ones who think it is a good idea to
use the feature, and people are not inclined to warn about things
they think are a good idea to use.
Although some implementations offer extended definitions and
this would be an incompatible change, the cost of that change
would be offset by the improvement in code portability.
Adoption Cost:
In most implementations, making this syntax legal is a matter of
a fairly localized change to a finite number of utilities which
reason about programs (compiler, interpreter, code walkers). No
changes to code which does not reason about programs would be
necessary.
In some implementations which have incompatible extension
strategies, such as keyword-driven facilities, the cost is higher
because this is an incompatible change. The cost of adoption in
such cases is hard to estimate; implementors who feel they have
severe concerns about this should raise those concerns and we'll
modify this proposal to reflect them.
Benefits:
Code portability between certain dialects would be improved.
Aesthetics:
The resolution of this controversial programming style issue
is left to the user rather than being forced by the language
designer. Those who prefer the symmetry of the (IF test then else)
syntax are free to use it exclusively without infringing on the
desires of others to use the extended syntax.
Some people find the alternatives to (IF test then {else}*) to
be too visually cumbersome.
Although IF was supposed to be a simple conditional form, usage
patterns suggest that this is not uppermost in many users' minds.
Experience in user communities where extended IF is available
show that few users object to its presence; most are happy for
the syntactic flexibility it provides.
Proposal (IF-BODY:UNCHANGED):
Leave IF as currently specified in CLtL.
Implicit in this proposal is that it would be valid for any
implementation to extend IF as long as such an extension was done
in a way that was `upward compatible' with Common Lisp.
Rationale:
The other two proposals are inadequately motivated.
Since some implementations already support extensions, it would
be disruptive to those implementations to require that the
extensions be removed. Not altering the current definition is
maximally conservative with regard to existing code.
Adoption Cost:
Making this syntax legal is trivial since everyone is
presumably already compatible with the existing standard.
Implicit in the acceptance of this proposal, however is the
incremental cost of late debugging of programs which are in error
but for which no diagnostic has been generated because we have
not required such a diagnostic.
Benefits:
The current state of the world would be unaffected.
Aesthetics:
The (IF test then else) syntax is neatly symmetric and this
symmetry should be preserved.
Some people find the asymmetry of the (IF test then {else}*)
syntax to be visually confusing.
IF is supposed to be the simplest conditional form, from which
all the others are built.
Current Practice:
Some implementations already provide this feature.
A few implementations provide alternate keyword-driven extensions
that are incompatible with the IF-BODY:LEGAL extension.
Some implementations signal an error if other than two or three
arguments are passed.
Some implementations quietly ignore additional arguments to IF (making
it hard to detect errors in code that was developed on systems with
the extended syntax).
Discussion:
MACSYMA ran into this problem.
KMP supports IF-BODY:LEGAL.
Steele and Fahlman support IF-BODY:UNCHANGED.
Moon has no strong opinion.
Fahlman expressed strong concern about the potential precedent which
could be set by using compatibility concerns as a lever to introduce
all kinds of unwanted idiosyncratic extensions present in only one
implementation and no other.
Moon suggested that the mere fact that some people like an extension
is not sufficient reason to put it into the language, but is
sufficient reason to -discuss- putting it into the language.
Steele notes that one of the reasons for including IF in the language
is to have a simple primitive that can easily be recognized, by people
and by program-walkers alike, as being the simplest conditional and
not having implicit PROGNs as do WHEN, UNLESS, and COND.
KMP thinks the language is already so cluttered that worrying about
such a tiny change to IF is unwarranted. He thinks that if the only
concern was primitive simplicity, we should just redefine the layer
at which simplicity is achieved by letting LISP:IF be a macro that
expands into PRIMITIVE:IF which has simpler semantics but which no
one has to be stuck programming with (if they don't want to). You
could argue that users should make their own JDOE:IF macro that has
this extension, but since this is likely to be a common extension, it's
our place to consider it for adoption as part of the standard.
∂29-Apr-87 1404 gls@Think.COM AREF-1D
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:04:18 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:19:45 EDT
Date: Wed, 29 Apr 87 15:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870429151657.4.GLS@BOETHIUS.THINK.COM>
Date: Fri, 24 Apr 87 01:52 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
In any case, although I did have reasons for the choice of name, I'm
not passionate about them. Since there's already a precedent for the
other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.
I am not passionate either. AREF-1D has the advantage of brevity.
By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
round out the set of operations which took an offset and either a list
of dimensions or an array and returned the standard reference pattern
might nicely round out the set of operations in this family...
This is a good idea.
--Guy
∂29-Apr-87 1406 gls@think.com AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:05:52 PDT
Received: from THINK.COM by navajo.stanford.edu with TCP; Wed, 29 Apr 87 14:04:23 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:20:50 EDT
Date: Wed, 29 Apr 87 15:17 EDT
From: Guy Steele <gls@think.com>
Subject: AREF-1D
To: edsel!bhopal!jonl@navajo.stanford.edu,
navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu, gls@think.com
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-Id: <870429151757.5.GLS@BOETHIUS.THINK.COM>
Date: Thu, 23 Apr 87 21:36:52 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed
very natural and "called for". So Lucid Common Lisp has had it available
since shortly thereafter.
Foo. It just goes to show that I can't remember what's in the book either.
∂29-Apr-87 1501 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 15:01:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 14:17:27 PDT
Date: 29 Apr 87 14:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870429-141727-2814@Xerox>
I put DEFVAR-INIT-TIME in the "we can release this soon" because I
presumed that it was so trivial there would be no objection. Usually its
a mistake to make any such presumptions, but one can always hope....
∂29-Apr-87 1722 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:22:30 PDT
Received: by navajo.stanford.edu; Wed, 29 Apr 87 17:22:02 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA01519; Wed, 29 Apr 87 16:33:45 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA13102; Wed, 29 Apr 87 16:30:59 PDT
Date: Wed, 29 Apr 87 16:30:59 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704292330.AA13102@bhopal.edsel.com>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 29 Apr 87 09:35 EDT
Subject: Issue: PROCLAIM-LEXICAL
In a deep-bound Lisp, it is critically important to be able to distinguish
"global" access/update from "special", or "fluid" access/update. A note
I sent to the CL mailing list about a year ago stressed this point; it
explained the semantic differences and showed some performance consequences.
There were not many replies about it since almost all Common Lisps are
currently shallow-bound [the upcoming Xerox effort will be an exception,
and some parallel research versions of Common Lisp are also an exception]
Since none of these proposals for clarifying the semantics of undeclared
variables propose to do away with "special" variables, then the question
of global/fluid distinction for "specials" is still relevant. So I'm a
bit concerned about the proposal to add yet a third environment, the
"global lexical", which doesn't address this concern.
Consider, for a moment, the example:
(let ((x 1))
(declare (special x))
(load "some-file"))
where the contents of "some-file" are
(setq x (+ x 3))
The historic interpretation is that this SETQ applies to the special
binding of x. To get the effect of setting the global "fluid" binding,
one would have to say something like
(proclaim '(global x))
(setq x (+ x 3))
or like
(locally (declare (global x)) (setq x (+ x 3)))
or use functions like Interlisp's "topval" functions:
(settopval 'x (+ (gettopval 'x) 3))
In this example, it would/should be illegal to lambda-bind x if it were
declared "global"; thus it is quite satisfactory to use the shallow-binding
value cell as both the "global" cell and the "special" cell; For many
reasons, it is very convenient to have the "top-level" fluid environment
be the same as the global environment.
That's why I'm a bit taken aback by your proposal that the "global lexical"
could not share with the global dynamic (fluid) environment. Whereas there
is the demonstrated need for a declaration which distinguishes special
variables from global variables, where is the need for a distinct, yet
parallel, global lexical environment?
-- JonL --
∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:44:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127770; Wed 29-Apr-87 20:26:29 EDT
Date: Wed, 29 Apr 87 20:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202621.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PRINC-CHARACTER:WRITE-CHAR.
∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:44:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127778; Wed 29-Apr-87 20:29:19 EDT
Date: Wed, 29 Apr 87 20:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202910.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor FORMAT-OP-C:WRITE-CHAR.
∂29-Apr-87 1844 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 18:44:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 18:45:08 PDT
Date: 29 Apr 87 18:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-184508-3208@Xerox>
Kent, I'll point out again that the proposal should not say "Change the
wording on p. 3241 to say...". The proposal should describe what ANSI
Standard Lisp should do, not what Guy Steele's second edition should
say. The words you use can be pretty much the same, but a number of
folks expressed some sensitivity that the cleanup committee not dictate
wording.
E.g., rather than
" Change the description of ~C on p389 to say:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment."
Proposal (FORMAT-OP-C:WRITE-CHAR):
The ~C option of format, when given a character with zero bits, will
perform the same action as WRITE-CHAR. (The behavior of FORMAT with the
~C directive given a character with non-zero bits attributes remains
unspecified.)
∂29-Apr-87 1926 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 19:26:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127905; Wed 29-Apr-87 22:26:18 EDT
Date: Wed, 29 Apr 87 22:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>
Message-ID: <870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I remember some of this being discussed before, and there being some
reason for not doing it that I couldn't remember, so I went back
through some old Common Lisp documents I have held onto. Here's
what I found:
21 Dec 1981 Issue #70 - we discussed the issue of what undeclared
free variable references mean, but couldn't decide. The alternatives
offered weren't very deep:
(a) interpreter and compiler warn
(b) interpreter never warns, compiler is permitted to warn
(c) "status quo" [it said] the interpreter never warns, but the compiler
never warns for top level forms, but is permitted to warn inside functions
21 Dec 1981 Issue #72 - we tentatively introduced a LOCAL declaration,
meaning not SPECIAL. This was by analogy with the UNSPECIAL declaration
of Maclisp and Zetalisp, but we decided to change the name. I don't
think we had completely understood the DECLARE/PROCLAIM distinction
at that time (although we were discussing it) so I'm not sure what
LOCAL meant as a proclamation; I think the idea was just that as a
declaration it could be used to shadow a SPECIAL proclamation.
8/14/82 I found a note of mine saying "there is no way to declare
a variable not special. I guess this got taken out when special was
changed not to be pervasive. This needs to be fixed."
8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
locally shadow a globally pervasive special declaration [I think that's
a special proclamation in current terminology]. I have written down that
"the vote was yes, GLS will propose, read JonL's paper". I don't have a
clue which JonL paper this refers to.
In all later documents, there is special but no unspecial nor local.
This confirmed my memory that a lexical declaration had been put in and
then taken out, but I was unable to find any written rationale for the
decisions, which is what I was really looking for. I didn't go so far
as to search the electronic mail archives (but I don't think they go
back all the way to 1981).
∂29-Apr-87 1951 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 19:51:22 PDT
Date: Wed, 29 Apr 87 22:53:15 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@MX.LCS.MIT.EDU
In-reply-to: Msg of Wed 29 Apr 87 16:30:59 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193127.870429.JAR@AI.AI.MIT.EDU>
Date: Wed, 29 Apr 87 16:30:59 PDT
From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
So I'm a bit concerned about the proposal to add yet a third
environment, the "global lexical", which doesn't address this
concern.
I'm having trouble understanding how you count environments. I count a
total of four:
1. lexical LAMBDA-bindings
2. global lexical
3. dynamic LAMBDA-bindings
4. global dynamic
KMP doesn't suggest ADDING a global lexical environment; the global
lexical environment is already there in the GENERAL and RESTRICTED
proposals. He merely suggests making it not be identical to the global
dynamic environment. This would make a total of 4 environments, not 3.
I tend to think of 2 and 4 as being part of 1 and 3. This is consistent
if you imagine that there's an immense cosmic LAMBDA surrounding all
the programs in the world; this LAMBDA binds all possible names.
I have no opinion at this point on the virtues of KMP's amendment.
In this example, it would/should be illegal to lambda-bind x if it were
declared "global"; thus it is quite satisfactory to use the
shallow-binding value cell as both the "global" cell and the "special"
cell...
This proposal is even more restrictive than RESTRICTED. I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. The RESTRICTED proposal seems to give you everything you want
-- it allows you to have a single global value cell in
shallow-dynamic-binding implementations, and it allows the desired
performance advantages in deep-dynamic-binding implementations. Why do
you want to rule out lexically lambda-binding global variables? Does
this have something to do with shallow lexical binding?
If I have told you something you didn't already know, or if you still
don't understand what I'm getting at, how can I make the proposals
clearer?
Jonathan
∂30-Apr-87 0053 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 00:53:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 00:52:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA03157; Wed, 29 Apr 87 23:47:27 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA13625; Wed, 29 Apr 87 23:44:42 PDT
Date: Wed, 29 Apr 87 23:44:42 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704300644.AA13625@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 29 Apr 87 22:26 EDT
Subject: Issue: PROCLAIM-LEXICAL
Re :8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
locally shadow a globally pervasive special declaration [I think that's
a special proclamation in current terminology]. I have written down that
"the vote was yes, GLS will propose, read JonL's paper". I don't have a
clue which JonL paper this refers to.
This "Common Lisp meeting" was held at CMU just after the 1982 Lisp
Conference. The "JonL paper" in question could hardly be anything
other than my contribution to that conference. It had a long title
something like "Constant Time Interpretation for Variables, in the
Presence of Mixed SPECIAL/LOCAL Declarations". It described the VAX/NIL
interpreter, and how it processed "special" and "unspecial" declarations
by pushing a block similar to what a lambda-binding would do, and
how the interpretation of a variable reference was resolved by comparing
"declarational level number" with "binding level number". It was full
of cute little acronyms, for which I can blame GLS.
I vaguely remember some flaming about LOCAL declaration being unnecessary
because, unlike in MacLisp, the SPECIAL declaration of Common Lisp wasn't
to be pervasive. As you say, I think the "flamers" totally blew it because
of not understanding the difference between DECLARE and PROCLAIM.
-- JonL --
P.S. The technique described in the above-mentioned paper was strictly
for a shallow-bound, non-parallel implementation. I don't think
I see how to generalize it otherwise.
∂30-Apr-87 1425 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:25:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 14:26:24 PDT
Date: 30 Apr 87 14:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142624-4291@Xerox>
I support DEFVAR-INIT-TIME as submitted.
If there is no objection, we can release it as is.
∂30-Apr-87 1429 Masinter.pa@Xerox.COM Re: Procedure for Steele's proposed clarifications
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:29:41 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 30 APR 87 14:29:41 PDT
Date: 30 Apr 87 14:31 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Procedure for Steele's proposed clarifications
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 13:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142941-4301@Xerox>
Many of the issues that are before us occured in Steele's list of
proposed clarifications, and, even though simple at first glance, seemed
to require the full-blown form.
If there is a subset of the clarifications which we can agree on without
discussion, then I'd be happy to proceed with them; if we all agree, we
can just submit them as a set of "obvious clarifications". I'm a little
skeptical that there are many like that. Do you have some candidates in
mind?
∂30-Apr-87 1459 Masinter.pa@Xerox.COM Re: Status of IGNORE-ERRORS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:59:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:12 PDT
Date: 30 Apr 87 14:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Status of IGNORE-ERRORS
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 16:25 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu, Daniels.pa@Xerox.COM
Message-ID: <870430-150012-4352@Xerox>
The only thing hanging up the signalling proposal is that that committee
(and mainly Kent Pitman) needs to bring it up before the next X3J13. It
is an excellent proposal and we should adopt it and get on with it.
There's no point in adopting IGNORE-ERRORS when we could get the whole
thing.
This was originally my paraphrase of Pavel's comments, but I've really
written what I think. At the meeting before X3J13 you were pretty
mysterious about your reasons for thinking the error proposal would take
too long, or longer than this committee would take.
Comments?
∂30-Apr-87 1502 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 15:01:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:55 PDT
Date: 30 Apr 87 14:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: IF-BODY (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 16:37 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870430-150055-4353@Xerox>
In the interest of getting this out of our hair, I think we could
release it as is. As a point for future proposals, I would like to
discourage "status quo" alternatives in enhancement proposals, since
every proposal has an implicit "status quo" alternative, and some of the
arguments are redundant. I had expected you would just elaborate in the
Discussions section, but ... whatever ...
Sometimes this process seems so mind-numbingly bureaucratic...
∂30-Apr-87 1638 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 16:38:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 16:37:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA06279; Thu, 30 Apr 87 16:13:47 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA01123; Thu, 30 Apr 87 16:11:01 PDT
Date: Thu, 30 Apr 87 16:11:01 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704302311.AA01123@bhopal.edsel.com>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu,
navajo!KMP%MX.LCS.MIT.EDU@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Wed, 29 Apr 87 22:53:15 EDT
Subject: Issue: PROCLAIM-LEXICAL
Re: KMP doesn't suggest ADDING a global lexical environment; the global
lexical environment is already there in the GENERAL and RESTRICTED
proposals. He merely suggests making it not be identical to the global
dynamic environment. This would make a total of 4 environments, not 3.
Since this "global lexical" environment isn't to be identical with the
"global fluid" environment, then it's a "new" environment as far as
Common Lisp is concerned; that's why I said he was "adding" something.
With respect to environments for a "free variable" reference, there are3,
not 4, possibilities. A lexically-bound variable isn't free, and hence
not, I thought, of concern to this discussion [which was opened up by your
attempt to clarify the semantics of free variables].
Have I misread anything here? Your proposals were clearly worded enough;
I only wanted to bring up an objection to the idea of having two totally
distinct global environments. I think calling it an "addition" or not
is a really minor point.
Re: . . . I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. . . .
I think you misread this completely backwards. It WASN'T that you couldn't
lambda-bind anything that had a binding in the global environment. It WAS
that you couldn't lambda-bind anything that was explicitly declared or
proclaimed GLOBAL rather than SPECIAL (or LOCAL?).
In an implementation where the global fluid environment is the same as
the top-level environment (the standard state for virtually all deep
and shallow bound Lisps -- but not for Lisp 1.5), then a SETting
of any variable without a dynamically intervening lambda-binding would
just make a global/top-level binding. This would happen independently
of whether the variable was proclaimed GLOBAL or SPECIAL. But a variable
delcared GLOBAL would only affect the top-level binding; not any
intermediate SPECIAL lambda-bindings.
Do you see the difference here? or does this point need more explication?
-- JonL --
∂30-Apr-87 1818 Masinter.pa@Xerox.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 18:18:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 16:46:05 PDT
Date: 30 Apr 87 16:48 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
Message-ID: <870430-164605-4496@Xerox>
fyi, this is the reaction from our local array expert...
----- Begin Forwarded Messages -----
Date: 30 Apr 87 15:07 PDT
From: Pedersen.pa
Subject: Re: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>:
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)]
In-reply-to: Masinter.pa's message of 30 Apr 87 14:17 PDT
To: Masinter.pa
cc: pedersen.pa
Don't really like either proposal -- because they seem like hacks
rather than a serious approach to the problem. Also, Common Lisp is
already over-bloated, it just doesn't need creeping featurism -- but
rather a trimming down. After all -- these proposals simply relieve the
user of the very minor chore of making displaced arrays for the rare
instances where that is the natural thing to do -- no real value is
added, but there is a cost in complexity, and possibly performance.
The truth is that if you really want to do multi-dimensioned array
manipulation, you really do want something like APL, or close to it.
Implementing an array calculus -- like APL -- is quite doable (I have
something close to that floating around), and is the right way to go for
heavy array users, but I don't think that functionality needs to be
built into the language.
J.P.
----- End Forwarded Messages -----
∂30-Apr-87 1901 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 19:01:20 PDT
Date: Thu, 30 Apr 87 22:03:41 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Thu 30 Apr 87 16:11:01 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193809.870430.JAR@AI.AI.MIT.EDU>
Date: Thu, 30 Apr 87 16:11:01 PDT
From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
With respect to environments for a "free variable" reference, there are3,
not 4, possibilities. A lexically-bound variable isn't free, and hence
not, I thought, of concern to this discussion [which was opened up by your
attempt to clarify the semantics of free variables].
OK, I see. "Free" means lexically free.
Re: . . . I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. . . .
I think you misread this completely backwards. It WASN'T that you
couldn't lambda-bind anything that had a binding in the global
environment. It WAS that you couldn't lambda-bind anything that was
explicitly declared or proclaimed GLOBAL rather than SPECIAL (or
LOCAL?).
Since you are implicitly proposing a third kind of declaration (GLOBAL,
in addition to SPECIAL and my proposed LEXICAL), I take this as an
implicit criticism of the proposal; you must consider it inadequate or
else you wouldn't be suggesting this new and different idea. I'm
wondering what
(PROCLAIM '(GLOBAL ...))
gives you that
(PROCLAIM '(LEXICAL ...))
doesn't. Forgetting our differences in conceptual model and terminology
for the moment, the ONLY difference I see between these (assuming the
RESTRICTED proposal), either semantically and pragmatically, is that a
variable that proclaimed GLOBAL cannot be lexically lambda-bound.
Therefore I don't see what GLOBAL adds to my proposal or why you are
suggesting that it's a good idea. (Certainly in the absence of
(PROCLAIM '(LEXICAL ...)), it is a good idea.)
I.e. I don't see how your "global" variables are different from my
"global lexical" variables.
Getting back to terminology: why do you think LOCAL is a better name
than LEXICAL? LEXICAL seems more general and more descriptive to me, as
long as you buy the idea that there is such a thing as a top-level
(global) environment, which serves as BOTH the top-level lexical
environment and as the top-level dynamic environment (unless KMP has his
way).
Jonathan
∂01-May-87 1536 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 15:36:11 PDT
Received: by navajo.stanford.edu; Fri, 1 May 87 15:35:37 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA09971; Fri, 1 May 87 13:15:07 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00639; Fri, 1 May 87 13:12:21 PDT
Date: Fri, 1 May 87 13:12:21 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705012012.AA00639@bhopal.edsel.uucp>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!KMP%AI.AI.MIT.EDU@navajo.stanford.edu,
navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Thu, 30 Apr 87 22:03:41 EDT
Subject: Issue: PROCLAIM-LEXICAL
I believe that the deep-binders would be satisfied with top-level
environment being called "global lexical", providing that the "global
special" (or, "global fluid" if you will) is the same. The main issue
is: What does a special reference mean when there is no dynamically
intervening special binding? Is it ok for it to access the "global
lexical" binding? I wouldn't want to go so far as to make an alternative
proposal, providing you agree that this is no problem with the single
top-level environment. [Larry -- could you volunteer some opinion?
This issue will probably affect Xerox's Lisp the most?].
Re: Getting back to terminology: why do you think LOCAL is a better name
than LEXICAL? LEXICAL seems more general and more descriptive ...
To me, "lexical" means "lexically apparent", or "lexically constrained".
In the example:
(DEFUN FOO (X) (DECLARE (SPECIAL X)) (LIST (BAR X) (BAR X)))
both instances of "X" in the calls to "BAR" are "lexical" with respect
to its binding; but "X" isn't lexically bound, it is dynamically bound.
[Note also; it is not "free".] Consider the (free) occurances of "X" in
some other module, which in fact might access the value of this binding;
they are not "lexically apparent". For this reason -- wanting to talk
about lexical context and not imply anything about the bindings of
variables therein -- I tend to prefer another term for the opposite of
SPECIAL. But I'm not at all enamored with the term LOCAL, or even
UNSPECIAL; LEXICAL would be ok as long as the documentation clearly
stressed this point.
-- JonL --
∂01-May-87 1656 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 16:56:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130001; Fri 1-May-87 19:56:58 EDT
Date: Fri, 1 May 87 19:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU,
Pedersen.pa@Xerox.COM
In-Reply-To: <870430-164605-4496@Xerox>
Message-ID: <870501195646.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 30 Apr 87 16:48 PDT
From: Masinter.pa@Xerox.COM
fyi, this is the reaction from our local array expert...
...
Date: 30 Apr 87 15:07 PDT
From: Pedersen.pa
... they seem like hacks rather than a serious approach to
the problem. ...
My guess is that it looks hackish more from a historical perspective
than it would if you just saw a new edition of the manual that didn't
refer to these as sequence functions. Surely if you were just told from
scratch that arrays were valid arguments to MAP or COUNT, you wouldn't
have thought it even remotely hackish. You'd likely say: "Of course."
I think your view may be skewed by feeling like we'll still have a sequence
functions chapter that will say "Oh, by the way, as a special case, MAP
and count will treat arrays as sequences displaced to their storage."
The argument about displacement is the rationale for the argument (and
for why it won't be efficient) more than advice for how the result might
be presented in the manual.
Pedersen: ... these proposals simply relieve the user of the very
minor chore of making displaced arrays for the rare instances where
that is the natural thing to do -- no real value is added, ...
Actually, I bet some people don't ever used displaced-arrays because
they seem like excess hair and/or because the side-effect consequences
are hard to learn about. RPLACA and RPLACD are hard to learn, but they
are taught about in lots of classes and lots of books so people
eventually catch on. Displaced arrays may be taught in some thorough
courses and one or two advanced books, but I bet are largely overlooked.
Not to mention the fact that they inherently seem to violate an
abstraction and some people might avoid them because of some feel that
programs which use them are not clean. On the other hand, there's
nothing even remotely unclean about using an operator like MAP or COUNT
on an array if that operator is willing to do the work for you. It's
not the machine instructions that count, it's what the program has to
say in order to make the machine instructions get executed that's of
interest.
Pedersen: ... but there is a cost in complexity, ...
I'd find it easier to remember a rule saying that "SUBSTITUTE does
top-level substitution in aggregate quantities" than one that says
"SUBSTITUTE does top-level substitution in vectors" because
"aggregate quantities" is a natural concept that I've been dealing
with for much longer than programming and "vector" is a domain
specialized (and in this case very arbitrary) restriction on that
natural concept. I'd consider it a simplification if SUBSTITUTE worked
on arrays.
Pedersen: ... and possibly performance. ...
I bet the performance hit is not remarkably large...
* I'd think compilers which can optimize these function calls
based on declarations could optimize this new case just as easily.
* Some implementations do microcode dispatch, so they don't have to
worry. Of the others, though, I'd bet most do a sequential type
dispatch that falls through to an error clause. If you put the
general array case right before the error clause, it's not costing
anyone but the people who want it (because they have to wade through
the other cases).
* Even so, since it's a constant-time operation to do this algorithm
selection and since all of these operations involve loops, the
performance hit even if you took one would be likely to get lost
in the dust.
* Touretzky effectively argues that there may be a speed improvement
because you can just check for type ARRAY and not check that it's
only a 1d array and go straight to business playing with its
elements. In some cases, this can speed things up by making it
possible to remove code that did what he is suggesting are
"gratuitous" error checks.
Pedersen: ... The truth is that if you really want to do
multi-dimensioned array manipulation, you really do want something
like APL, or close to it. Implementing an array calculus -- like APL
-- is quite doable ... and is the right way to go for heavy array users ...
Well, of course, Touretzky says outright in the proposal that he realizes
this is a harder problem and that he doubts that we would be interested
in solving that, but that the solution to the simpler problem would be
significantly interesting to him certainly and perhaps to others (a
claim that I think he gives a credible case for).
Moreover, the more interesting case is for people who are -not- heavy
array users. They just have one array and they're in some place where they
want to count certain elements. Having to write a routine to do this can
distract from the true purpose of the function, which may be unrelated
to the array issue.
I was recently looking back over a lot of old Maclisp code I wrote
around 1979-80. I was struck by the number of times I'd written utility
functions that got used only once -- many things that now are (fortunately)
available in the system. Getting up to a conversational level with Lisp
took most of the effort -- the programs were trivial by modern standards.
I had friends who wrote shorter (but I'd say less intelligible) programs
where they didn't take the time to abstract things out and so in the
middle of some program there'd be a couple of nested DO loops taking the
MAX of something which was not very relevant in the grand scale of things,
but which took up a lot of syntactic space.
I think it's reasonable for us to consider minor extensions that aid
this end of just making certain utilities be common so that they needn't
be written be written time and time again unnecessarily. I think this is
what Common Lisp is about.
∂01-May-87 1933 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 19:33:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:34:05-EDT
Date: Fri, 1 May 1987 22:34 EDT
Message-ID: <FAHLMAN.12299038089.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 21 Apr 1987 15:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I have had applications which for various reasons I can't go
into in detail where I needed to have a keyword which no one
but myself would use.
Come on, doesn't anyone have a short, coherent example that demonstrates
the need for a non-keyword as a "keyword" argument? If the goal is to
have publically accessible functions that take hidden arguments, I'd
like to see an explanation of the need for this. Seems to me like a
pretty bogus way to do encapsulation, but maybe I'm missing something.
Testimonials are fine, but it's going to be hard to sell this proposal
without a coherent explanation.
-- Scott
∂01-May-87 1947 FAHLMAN@C.CS.CMU.EDU ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 19:47:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:48:23-EDT
Date: Fri, 1 May 1987 22:48 EDT
Message-ID: <FAHLMAN.12299040692.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
In-reply-to: Msg of 22 Apr 1987 16:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I don't like this proposed extension. It seems confusing and dangerous
to do the destructive operation in some cases and a copy in other cases.
I think that I would be more comfortable with some sort of COPY-ARRAY
function, though I'd need to see the details in order to be sure.
-- Scott
∂01-May-87 2030 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 20:29:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130098; Fri 1-May-87 23:30:18 EDT
Date: Fri, 1 May 87 23:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299038089.BABYL@C.CS.CMU.EDU>
Message-ID: <870501233004.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I have a Version 2 of this issue waiting for Moon to look it over before sending it
out. The following text is excerpted from that proposal. Does it look any better
to you?
Rationale:
By allowing symbols other than keyword symbols as keywords, we provide
a more private communication channel between functions.
Also, applications such as the emerging object-oriented standard which
must reliably merge keywords coming from different sources (some internal
and some user-supplied) can work more reliably by exploting this new
partitioning of keyword names. For example, a public routine MAKE-FOO
might need to accept arbitrary keywords from the caller and might want
to pass those keywords along to an internal routine using keywords of
its own.
For example,
(IN-PACKAGE 'SYSTEM)
(DEFUN MAKE-INSTANCE (TYPE &REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-INSTANCE-INTERNAL TYPE 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would override
some keyword in keyword-value-pairs since the only way that could happen
is if someone had done (MAKE-INSTANCE 'ZEBRA 'SYSTEM::EXPLICIT NIL), or
if the user was programming explicitly in the SYSTEM package, either of
which is an implicit admission of willingness to violate SYSTEM's modularity.
∂01-May-87 2037 FAHLMAN@C.CS.CMU.EDU UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 20:37:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 23:26:54-EDT
Date: Fri, 1 May 1987 23:26 EDT
Message-ID: <FAHLMAN.12299047704.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
In-reply-to: Msg of 23 Apr 1987 02:07-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Larry's status report says that this issue has been agreed...
I never agreed to this, and I think you are overlooking something.
Well, it should have been "agreed by those present at the pre-X3J13
meeting", I guess.
Therefore I propose that case 1, transfer to a point inside the point to
which control would have transferred, not do the second throw. There
are two things we could require it to do instead (or we could just
wimping out and say it "is an error"). It could signal an error, or
it could resume the original throw, just as if the cleanup handler had
exited normally. I prefer signalling an error, because I firmly believe
that the program is ill-formed.
I think you've spotted a case that the rest of us missed. At least, it
didn't come up in earlier discussion. I'm not completely sure what is
right, but I'm inclined to agree that "signals an error" is the right
thing here, rather than just allowing the throw whose tag is outermost
to win. I've got a hunch that trying to do the latter would just
introduce another layer of subtle problems.
Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
I guess we need a class of errors that don't get ignored, despite the
user's instructions. There are probably some other members of this
class. Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.
-- Scott
∂01-May-87 2115 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 21:15:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:16:48-EDT
Date: Sat, 2 May 1987 00:16 EDT
Message-ID: <FAHLMAN.12299056786.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 1 May 1987 23:30-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Yeah, that's the sort of example I was looking for. I see what you're
driving at now, but the example of Make-Instance doesn't seem terribly
compelling. One might question whether this is the best way, or even a
reasonable way, to pass this collection of stuff on to
Make-Instance-Internal. Why pass Explicit as a keyword at all? Why not
as a required arg, since the target function has to be ready to handle
Explicit in any event. Seems like you're just muddling things together
and that the callee will have to un-muddle them again.
In any event, I suppose that this is a legitimate style, even though I
think it is ugly and probably inefficient. Since the proposed change is
fairly harmless, this example probably provides enough motivation for it.
-- Scott
∂01-May-87 2128 FAHLMAN@C.CS.CMU.EDU Issue DEFVAR-INIT-TIME (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 21:27:55 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:29:01-EDT
Date: Sat, 2 May 1987 00:28 EDT
Message-ID: <FAHLMAN.12299059010.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue DEFVAR-INIT-TIME (Version 1)
In-reply-to: Msg of 23 Apr 1987 16:59-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
This looks OK to me.
I believe that the cause of the confusion is really the statement that
the initial value form is not evaluated unless "it is used". Better to
say that INITIAL-VALUE is evaluated if and only if the variable does not
already have a value. Then I think that there would be no confusion
about the time of evaluation, though it can't hurt to spell this out
explicitly.
-- Scott
∂01-May-87 2145 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 21:44:57 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130133; Sat 2-May-87 00:45:09 EDT
Date: Sat, 2 May 87 00:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299056786.BABYL@C.CS.CMU.EDU>
Message-ID: <870502004454.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sat, 2 May 1987 00:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
... One might question whether this is the best way, or even a
reasonable way, to pass this collection of stuff on to
Make-Instance-Internal. Why pass Explicit as a keyword at all? Why not
as a required arg ...
What if MAKE-INSTANCE-INTERNAL takes 47 such internal keywords? Just
because I only used one in the call doesn't mean that's all it receives.
Would you have me pass all 47 internal arguments on every call?
Also, the caller of MAKE-INSTANCE might be within package SYSTEM and so
it might not be an abstraction violation for him to pass other packaged
symbols. That means that more keywords than those you see might be being
received in the main arglist, though presumably none that the caller
worries are going to be overridden by MAKE-INSTANCE.
Or there might be other situations in which keyword-style calling is
more important than in the particular call that you have there.
I could add some of these issues to the add rationale, too, if you like.
Almost by definition, any two-line example is not going to leave you
feeling satisfied about something which is claimed to be useful in
complex situations involving modularity boundaries.
Anyway, the fact that you can figure out what is being hinted at by the
small example makes me feel like the example did its job.
∂02-May-87 0707 FAHLMAN@C.CS.CMU.EDU DELETE, SORT, ADJUST-ARRAY considered harmful
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 07:07:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 10:08:35-EDT
Date: Sat, 2 May 1987 10:08 EDT
Message-ID: <FAHLMAN.12299164519.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@THINK.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful
In-reply-to: Msg of 25 Apr 1987 03:25-EDT from Guy Steele <gls at think.com>
Well, maybe the proposed syntax stinks, but perhaps some way of
idiot-proofing destructive operations should nevertheless be found.
Nothing is foolproof because fools are so ingenious. (Who said that?)
I don't think that it is a good idea to go back and diddle with these
old problems at this point. Destructive operations on lists are tricky
in N other ways as well, so you've got to stop and think. I wouldn't
mind a "chatty" compiler mode that warns of a possible problem whenever
it sees a DELETE not in a setting form, but this is not a standards-type
issue.
Since you signed this "Quux", I'll assume that you don't really want to
push it.
-- Scott
∂02-May-87 1143 FAHLMAN@C.CS.CMU.EDU IF-BODY (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 11:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 14:43:57-EDT
Date: Sat, 2 May 1987 14:43 EDT
Message-ID: <FAHLMAN.12299214648.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY (Version 5)
In-reply-to: Msg of 27 Apr 1987 18:21-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I hate to keep beating on this, but we're working on developing internal
procedures for handling controversial cases, and it probably is worth
trying to debug these procedures on a stupid case like this before
something really hard comes along. I think we've got the wrong model
here for dealing with controversial things. It is unreasonable to ask
one person to produce a balanced presentation that fairly summarizes all
points of view, including views that he disagrees with.
KMP's latest version of the IF-BODY proposal is a case in point. It
represents a good-faith attempt on his part to present a balanced
discussion of the issues, but the result is nevertheless unbalanced in
subtle ways toward his point of view. I'm not trying to dump on KMP
here -- if I had written the summary, I'm sure it would be even more
biased the other way.
KMP states at the outset that some implementations, if allowed to, will
implement this extension, and that these extended implementations will
"typically" not generate a warning. Later he argues that encouraging
(but not requiring) a warning is inadequate, because an implementation
that adds this feature must think it is a good idea, and you don't warn
about good ideas. This ignores the possibility of a "warn me about any
non-portable code" compilation mode, which is the right solution
(assuming this IF-BODY problem is troublesome enough that it is worth
fixing at all). If an implementor doesn't choose to support such a
mode, fine; that's between him and his customers. But don't ask the
rest of us to mess up the language in order to make that
implementation's users more comfortable -- if the vendor doesn't want to
employ the obvious simple technique for solving this problem, then it
presumably isn't worth solving. I've stated this view N times before
and this "somebody prepare a summary" process keeps eviscerating the
argument. Again, it is the process that is at fault, not the people
doing the summarizing.
It seems to me that the process should go something like this: Person X
proposes a compatible extension. If, after some discussion, consensus
is reached on some (possibly amended) version of the extension, we put
that version forward as a proposal, with some sort of joint rationale in
the discussion section. If the committee doesn't like the proposal and
can talk the proposer into dropping it, fine, we drop it. If there is
no consensus in favor of the change, but the proposer wants to present
the matter to the full X3J13, then he should prepare the most persuasive
argument he can muster -- none of this "balance" stuff. Then, in the
discussion section, the opposition gets to have its say. The point is
that each side of the case must be argued by someone who believes in it.
Just like the lawyers. I suppose that in some cases, there might be
more than one dissenting opinion: various people might dislike a
proposal for different reasons.
There remains the question of who gets the last word. We could iterate
until quiescence or exhaustion is reached, flip a coin, or establish
some arbitrary guideline. I guess I'd say that the proposer gets his
say, then the negative voices, and finally the proposer gets a short
rebuttal (confining himself to answering what the opposition said,
rather than introducing new arguments). The result is concatenated, not
summarized, for presentation to the outside world.
The above assumes that the question is whether or not we should adopt
some change. In a situation where there are N positive proposals to
choose from, all with their advocates, then a FOO:A, FOO:B, FOO:C
approach is appropriate. The arguments in favor of each position should
be presented by the advocates of that position, if any exist. In the
case of a yes/no question, it is silly to have separate FOO:YES and
FOO:NO proposals.
-- Scott
∂02-May-87 1220 FAHLMAN@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 12:20:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 15:21:49-EDT
Date: Sat, 2 May 1987 15:21 EDT
Message-ID: <FAHLMAN.12299221539.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Msg of 28 Apr 1987 14:13-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I have no strong opinion on this proposal. It doesn't look to me like
it would add much confusion, it wouldn't be too hard to implement, and
apparently some people would find it useful. So I guess I'm mildly in
favor of either the GENERALIZE or the MODIFIED version.
I would not like to see this leave committee in the current format.
Maybe KMP, Touretzky, Rees, and anyone else who cares can work out a
single proposal that they all like. The paths not taken can be
mentioned in the discussion section.
I would like to encourage KMP to go ahead with a separate proposal for
ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it). Given that, I
think a version of POSITION that returns a single number for arrays is
probably the way to go, and users can then turn this into a subscript
list if they like. I have a mild aversion to getting a list from some
function that has heretofore always returned a number or NIL.
In choosing issues to introduce in the future, we probably should lean
toward doing clarifications first and saving extension for later.
-- Scott
∂02-May-87 1313 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:13:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:13:50-EDT
Date: Sat, 2 May 1987 16:13 EDT
Message-ID: <FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 28 Apr 1987 16:35-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
<Is JAR on CL-CLEANUP now? If not, we should all include him in the
address list while discussing this.>
I think that this proposal is confused. The current rule for handling a
reference to a variable that is neither bound nor declared is
unambiguous: the variable is assumed to be special. There is no
ambiguity and no need for clarification. Whether we want to change this
is another question, and an interesting one.
However, if you feed this program to many Common Lisp compilers
(including Symbolics's and DEC's), a warning message will be
produced for the SETQ, saying something like "Warning: X not
declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so
prominently that a user would be hard put to say that a program
which elicited such warning messages was "correct" in that
implementation. Unlike the situation with unused variables, there is
no possible declaration one can write which suppresses the warning
messages.
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal. The more
of this a compiler does, the better it is as a debugging aid (up to the
point where the "crying wolf" effect sets in because too many spurious
warnings are being generated). The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo. In the latter case, I want to see a warning. If you
tell me that I can can't use a warning here because it looks too much
like an error, then I'll have to create yet another kind of compiler
output ("mild suggestion?") with which I can report these things.
I prefer to retain the term warning for this, and to use the term "error"
when there really is an error.
If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Then people who hate to see any warnings can get rid of them, and those
of use who use them for debugging can have them. But I see nothing
unacceptable or even uncomfortable about the status quo. Probably the
spec should explaint he difference between an error and a warning rather
than leaving this to the reader's imagination.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free. But we should
not muddle this into a discussion of the current rules or the difference
between warnings and errors in the compiler.
-- Scott
∂02-May-87 1324 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:24:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:25:02-EDT
Date: Sat, 2 May 1987 16:24 EDT
Message-ID: <FAHLMAN.12299233050.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FORMAT-OP-C (Version 2)
In-reply-to: Msg of 29 Apr 1987 12:38-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support this proposl. I think that the presentation should be
simplified before it goes out. Most of the lengthy discussion in the
problem description is unnecessary. This is a simple clarification.
-- Scott
∂02-May-87 1340 FAHLMAN@C.CS.CMU.EDU PRINC-CHARACTER (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:30:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:31:09-EDT
Date: Sat, 2 May 1987 16:31 EDT
Message-ID: <FAHLMAN.12299234147.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PRINC-CHARACTER (Version 2)
In-reply-to: Msg of 29 Apr 1987 15:46-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I favor PRINC-CHARACTER:WRITE-CHAR.
-- Scott
∂02-May-87 1616 JAR@AI.AI.MIT.EDU Is JAR on CL-CLEANUP now? Yes.
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 16:16:03 PDT
Date: Sat, 2 May 87 19:18:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Is JAR on CL-CLEANUP now? Yes.
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987 16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194617.870502.JAR@AI.AI.MIT.EDU>
I'm on CL-CLEANUP.
∂02-May-87 1655 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 16:55:26 PDT
Date: Sat, 2 May 87 19:58:08 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987 16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194629.870502.JAR@AI.AI.MIT.EDU>
Date: Sat, 2 May 1987 16:13 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
*Not* not true! Look again at the example. If you declare the variable
special, you will change the semantics of the program. In this example
you would also have to rename every X that's lexically bound; being an
extremely non-local transformation, this is unacceptable.
In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal.
I basically agree with this, but you should note that every other sort
of warning is avoidable. E.g. an unreferenced bound variable is often a
result of a program error, but when it's not it can be dealt with by
(DECLARE (IGNORE ...)); an OR with only one subform can be a symptom of
a misplaced parenthesis, but where it's the right thing there are ways
to get around the problem (make your macros smarter...). But in this
case the only way to get rid of the warning is either by
alpha-converting or by making the program possibly incorrect, which is
definitely unfriendly.
I don't know how you develop code, but I like to get my programs into
a condition where they do not elicit warnings from the compiler.
The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo.
Why is this any different from an undefined function, which is not
similarly warned about? I believe these two situations (forward
reference to a variable and to a function) should be treated
symmetrically.
If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Unacceptable in this case (unless we adopt BY-THE-BOOK); many warnings
are quite desirable. I would say a warning is OK if either it indicates
that an error will happen at run time, or if the code is truly is dubious
style AND there is an easy way to fix or annotate the code so that the
warning goes away.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free.
If you look at the proposal carefully you'll see that it contains
exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
can do (PROCLAIM '(LEXICAL ...)). I'm wondering how you missed it,
although if you only looked at the summary at the top and not the rest
of the message, that would explain it; the introduction is admittedly
misleading. I'll fix that next time around.
Like I said in the "Status:" line, this is very preliminary.
Jonathan
∂02-May-87 1720 FAHLMAN@C.CS.CMU.EDU Is JAR on CL-CLEANUP now? Yes.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 17:20:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 20:20:35-EDT
Date: Sat, 2 May 1987 20:20 EDT
Message-ID: <FAHLMAN.12299275925.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Is JAR on CL-CLEANUP now? Yes.
In-reply-to: Msg of 2 May 1987 19:18-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Good. Wasn't sure if you were seeing things routinely or if KMP was
just passing you selected tidbits.
-- Scott
∂02-May-87 1855 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 18:55:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 21:56:52-EDT
Date: Sat, 2 May 1987 21:56 EDT
Message-ID: <FAHLMAN.12299293460.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 2 May 1987 19:58-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
In reply to JAR:
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
*Not* not true! Look again at the example.
...
I don't know how you develop code, but I like to get my programs into
a condition where they do not elicit warnings from the compiler.
OK, if you really want to use the same names for your specials and your
lexicals, then indeed there is no good way to get rid of the warning. I
hardly ever do this, so I missed your point. When I see that warning in
a case like your example program, it tells me that it's time to rename
something, not that I should find some way to inhibit the warning with a
declaration.
I assume that we're not going to consider any radical proposals for the
handling of specials, such as separating the name spaces by making the
*foo* syntax mandatory for specials. If we stay close to the status
quo, it seems to me that we really should go ahead and add a LEXICAL
declaration and a LEXICAL proclamation so that those pervasive special
proclamations can be cancelled or shadowed. I haven't heard any good
arguments against this in the last N years. The need to eliminate
spurious "not declared or bound" warnings is one argument in favor of
this change, but it would be a useful change for other reasons in any
case.
Why is this any different from an undefined function, which is not
similarly warned about? I believe these two situations (forward
reference to a variable and to a function) should be treated
symmetrically.
No difference in principle. Both conditions are suspicious and worth a
warning, in my view, but how such warnings are handled is up to the
implementor. It is desirable to emit these warnings when the suspicious
condition is noticed; that way the location of the problem is marked and
the user has the option of aborting the compilation. In the case of
undefined functions, forward references are particularly common, so most
implementations wait till the end of the compilation before emitting the
warning. In the case of undeclared specials, there does not seem to be
a good reason to wait, so we warn at once.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free.
If you look at the proposal carefully you'll see that it contains
exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
can do (PROCLAIM '(LEXICAL ...)). I'm wondering how you missed
it...
I didn't miss it. Your GENERAL and RESTRICTED proposals seem to re-open
a debate that we had some time ago on "global" or "global lexical"
variables and what their semantics should be. A lot of hairy issues
came up in that discussion, and I didn't see those issues being
addressed here. So my suggestion was that we ought to separate this
issue from the business about inhibiting warnings and try to come up
with a comprehensive proposal on global variables -- comprehensive in
the sense that we try to deal with all the issues raised in the earlier
discussion.
-- Scott
∂04-May-87 1056 Masinter.pa@Xerox.COM Issue priority
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 May 87 10:56:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAY 87 10:54:17 PDT
Date: 4 May 87 10:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue priority
to: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870504-105417-2905@Xerox>
We've been asked by some members of the object proposal to quickly
address the issues that they are waiting on.
Those issues include:
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-TYPE
and an issue, currently not written up, on whether the types STREAM,
PACKAGE, PATHNAME, READTABLE and RANDOM-STATE can be required to be
disjoint from other types (e.g., as if they had been created with
DEFSTRUCT.)
I didn't see any strong objections to these proposals, except for the
way in which they were worded.
If you'd like to discuss any of these issues, you will make my life
simpler if you will send separate messages about each.
∂04-May-87 1423 KMP@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 May 87 14:23:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131431; Mon 4-May-87 17:22:42 EDT
Date: Mon, 4 May 87 17:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: Fahlman@C.CS.CMU.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299047704.BABYL@C.CS.CMU.EDU>
References: The message of 23 Apr 1987 02:07-EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
The message of 29 Apr 1980 16:09-EDT from Jon L White <JONL at MIT-MC>
Message-ID: <870504172241.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 1 May 1987 23:26 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In-reply-to: Msg of 23 Apr 1987 02:07-EDT
from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
...
Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
Personally, I consider the meaning of this to be well-formed. It'd be
sad for a programmer to get into this, but I think that in this case
the user has pretty clearly asked to have a loop that cannot be exited
and deserves to have that request carried out.
Consider how ridiculous it would have looked on Star Trek when they
needed to divert the computer's attention and said "Computer, compute to
the last digit the value of pi". If I recall, Spock makes a remark like
"As you know, the value of pi is a transcendental number without
resolution. ... The computer will work on this problem to the exclusion
of all else ...". Imagine how frustrated he'd have been if the computer
had refused to execute the command because it didn't seem like he really
meant what he said.
Well, ok, so this isn't the most likely scenario. But the truth is,
as Prof. Bill Martin said once in a linguistics class I took from him --
We create syntax in a language not to allow us to say the things that
are obvious, but so that we can say things that are not obvious. If we
didn't need to say things that were not obvious, we'd just jumble all
the words together and assume people would figure out some uniquely
determined, obviously useful interpretation. In fact, we make careful
rules to allow us to say bizarre things not so we can say bizarre things
all the time, but so that if there comes a time to say such things, we
won't be at a loss for words.
By the way, I did once write a CL program that wanted the semantics that
Moon claims are implausible. In Common Lisp, there was no portable way to
make a Lisp have a Macsyma toplevel (ie, where the vendor's abort character
would return me to Macsyma and not to Lisp). So I wrote something which did
effectively:
(DEFUN MACSYMA-TOPLEVEL ()
(PROG ()
LOOP (UNWIND-PROTECT (REALLY-MACSYMA-TOPLEVEL)
(GO LOOP))))
so that people who'd invoked Macsyma toplevel couldn't get back to toplevel
lisp. So while it might be rare, it's not unthinkable that someone could really
write this and mean what they said...
As such, I don't rate this desire to let the user intervene at the same
level of importance that Moon does. However, since I do find it an
interesting issue, I'm willing to entertain the issue for discussion
for now without prejudice to its ultimate importance.
I guess we need a class of errors that don't get ignored, despite the
user's instructions. There are probably some other members of this
class. Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.
If we did make this illegal, I'm curious exactly what Moon would want to
have happen here. The most plausible scenario I can come up with that fits
in this hypothetical framework is the following (which is essentially like
what Scott is suggesting) ...
THROW could notice that it was going to THROW to a point inside
a THROW which was already active. At this point, it could signal
a SERIOUS-CONDITION (some type which was not a subtype of ERROR),
so that IGNORE-ERRORS did not catch the condition, but that did
have a default handler that would force entry into the debugger.
This would allow an opportunity for user-intervention.
The debugger could offer options which should include:
* Going ahead with the inner THROW (and discarding the outer
THROW attempt).
* Exiting from this UNWIND-PROTECT cleanup body and continuing
the ongoing THROW.
* Blowing away the process without running its UNWIND-PROTECT
cleanups.
This would allow for user intervention without precluding what
I believe to be the clean semantics (choice C). I'm suspicious
of any choice which doesn't even allow the user to get style-C
semantics if that's what he wants.
Dave, is this the sort of thing you're proposing? If not, could
you please sketch what you are suggesting for contrast?
By the way, I ran across the following piece of mail the other day
while looking around for something else. I just thought you'd be
interested to know that this problem is as old as UNWIND-PROTECT
itself; the message is from only a few days after UNWIND-PROTECT
was first installed in Maclisp and although the bug is not like
the one we're discussing, the test scenario is a lot similar to
the code sketch Moon did above...
-----Forwarded Message Follows-----
Date: 29 April 1980 16:09-EDT
From: Jon L White <JONL at MIT-MC>
To: KMP at MIT-MC, RWK at MIT-MC
cc: BUG-LISP at MIT-MC
Subject: UNWIND-PROTECT
On the 15th of Feb, KMP sent out a bug notice about UNWIND-PROTECT
losing, for which I made the diagnosis that ERRSET was not saving
and restoring the UNREAL flag. The test case is
(DEFUN KMP-LOSES () (ERRSET (UNWIND-PROTECT NIL (OPEN '((DSK BOO) BAR BZ)))))
Well, I found a way to fix ERRSET without taking more pdl locations,
and the assembled code (already initialized) is on LISP;BBLISP 995QIO.
...
∂04-May-87 1919 FAHLMAN@C.CS.CMU.EDU Issue priority
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 May 87 19:19:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 4 May 87 22:18:19-EDT
Date: Mon, 4 May 1987 22:18 EDT
Message-ID: <FAHLMAN.12299821653.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue priority
In-reply-to: Msg of 4 May 1987 13:56-EDT from Masinter.pa at Xerox.COM
KEYWORD-ARGUMENT-NAME-PACKAGE
I believe that KMP is working on a version that explains why a change is
needed. The lack of such an explanation was my only real objection.
FUNCTION-TYPE
On my queue, but I've got a funding proposal to get out by the end of
the week, so this stuff won't get worked on until next weekend. If
anyone else can grab it sooner, feel free.
and an issue, currently not written up, on whether the types STREAM,
PACKAGE, PATHNAME, READTABLE and RANDOM-STATE can be required to be
disjoint from other types (e.g., as if they had been created with
DEFSTRUCT.)
I don't think we currently require structures to be a disjoint
type from vectors, etc., though this has been talked about. So that
should be part of any proposal.
∂05-May-87 1416 pedersen.pa@Xerox.COM Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 May 87 14:15:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAY 87 14:15:02 PDT
Date: 5 May 87 14:14 PDT
From: pedersen.pa@Xerox.COM
Subject: Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 1 May 87 19:56 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu,
Dave.Touretzky@C.CS.CMU.EDU, Pedersen.pa@Xerox.COM
Message-ID: <870505-141502-1099@Xerox>
Pitman:
"Actually, I bet some people don't ever used displaced-arrays because
they seem like excess hair and/or because the side-effect consequences
are hard to learn about. ... Displaced arrays may be taught in some
thorough
courses and one or two advanced books, but I bet are largely
overlooked...
Not to mention the fact that they inherently seem to violate an
abstraction and some people might avoid them because of some feel that
programs which use them are not clean."
I find a certain inconsistency in your argument that constructing
displaced-arrays is obtuse and unesthetic, while at the same time
stating that multi-dimensional arrays are naturally operated on as
vectors with elements laid out in row-major order. After all,
displaced-arrays are the only mechanism in common lisp that allows one
to adopt that view, and as such are indispensible. Indeed, one might
argue that for the inexperienced Lisp user, who has some knowledge of
"C" or "FORTRAN", displaced-arrays map directly into conventional use of
pointers into arrays.
On a more constructive note -- it seems like a small addition to the
array mechanism might address most of our concerns. Consider:
(defun flatten-array (array)
(cond ((vectorp array) array)
((arrayp array)
(make-array (array-total-size array)
:element-type (array-element-type array)
:displaced-to array))
(t (error "Not an array: ~s" array))))
then "flatten-array" may be used in combination with sequence functions
to achieve the desired semantics, and would have the advantage of making
clear the intention of a code fragment. A primitive like "flatten-array"
is useful in other contexts as well, and would complement a
"row-major-aref" primitive.
J.P.
∂10-May-87 1154 FAHLMAN@C.CS.CMU.EDU [RAM: exiting from unwind protects]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87 11:54:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 14:54:06-EDT
Date: Sun, 10 May 1987 14:54 EDT
Message-ID: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [RAM: exiting from unwind protects]
I find the following pretty persuasive...
Date: Saturday, 2 May 1987 11:16-EDT
From: Rob MacLachlan <RAM>
To: fahlman
Re: exiting from unwind protects
ReSent-Date: Sun 10 May 87 10:56:56-EDT
ReSent-From: Rob.MacLachlan@C.CS.CMU.EDU
ReSent-To: fahlman@C.CS.CMU.EDU
ReSent-Message-ID: <12301270482.15.RAM@C.CS.CMU.EDU>
I don't really agree with Moon about this thing. I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug". Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion. After a while I got bored of
trying to throw out of the break loop, and I quit.
If I had really been doing anything, I could always have skipped over
the losing frame using debug-return. Environment problems can have
environment solutions. In any case, I could have saved work I was
doing from the break loop. This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water. What happened the last time you did
(makunbound '*terminal-io*)?
In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain. It seems that Moon has already introduced
three new things into the language:
1] The concept of "throwing out of an unwind protect cleanup". When
are you in an unwind protect? What does it mean to throw out of
it? Does this apply to lexical exits too? Does this signal an
error?
(block block
(unwind-protect <foo>
(return-from block)))
Does this?
(unwind-protect <foo>
(block block
(return-from block)))
2] The concept of errors that aren't errors, which we need so that
users can't screw themselves with this feature no matter how hard
they try.
3] The implicit requirement that an implementation have some exit
mechanism other than throw so that it can unwind out of cleanup
forms even if the user can't. What does the system do when you
are running in an unwind protect and the user types an interrupt?
In fact, it seems that Moon is being inconsistent here, since he
has already assumed that interrupts do throw. If the user
interrupts when running in a cleanup do you signal an error, and
then signal an error whenever the user tries to abort out of the
debugger?
If I had ever been screwed by this, I would think differently. I'm
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups. There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
error.
I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form. Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.
Rob
∂11-May-87 1051 RPG Draft of revised FUNCTION-TYPE
∂10-May-87 1852 FAHLMAN@C.CS.CMU.EDU Draft of revised FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87 18:52:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 21:51:36-EDT
Date: Sun, 10 May 1987 21:51 EDT
Message-ID: <FAHLMAN.12301389651.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: rpg@SAIL.STANFORD.EDU
Cc: masinter.pa@XEROX.COM
Subject: Draft of revised FUNCTION-TYPE
Dick,
I said I'd give you a shot at this before sending it to the whole
Cleanup list. Want to make a pass and see if this captures what we all
agreed to. I'm not too confident of my ability to use the right terms
for these lexical variables and things, so please keep an eye out for
that. I'm CC'ing Masinter just so he'll know that progress is
progressing progressively. It would be good to get thsi out within a
few days, since the CLOS people seem to need this to be settled.
-- Scott
---------------------------------------------------------------------------
To: cl-cleanup at SAIL.STANFORD.EDU
Re: Issue: FUNCTION-TYPE (version 3)
Status: Revised by SEF to reflect intensive discussions prior to the
last X3J13 meeting.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function type into the CLOS class hierarchy.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Change this to the following:
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
Rationale:
This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
fahlman@c.cs.cmu,masinter.pa@xerox/su
Function Type Proposal
I think it looks good as you have it. Fire away.
-rpg-
∂11-May-87 1256 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 12:56:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 15:55:55-EDT
Date: Mon, 11 May 1987 15:55 EDT
Message-ID: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (version 3)
Status: Revised by SEF to reflect intensive discussions prior to the
last X3J13 meeting.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Change this to the following:
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
Rationale:
This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
∂11-May-87 1420 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 14:20:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137159; Mon 11-May-87 17:18:50 EDT
Date: Mon, 11 May 87 17:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870511171840.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 11 May 1987 15:55 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
I (apparently somewhat belatedly!) approve of FUNCTION-TYPE:REDEFINE
except with the following two caveats:
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
Common Lisp currently defines a type-specifier named COMPILED-FUNCTION.
Is this a proposal to remove it? I would probably support such a proposal,
but it should be explicit.
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
The phrase "signal an error if it is unable to do so" is new. My
problem is that the concept of "unable to compile" is not defined and is
open to varying interpretations. For example, does this mean that if
any compiler warnings are issued, COMPILE should signal an error at the
conclusion of the compilation? Also, if we assume that the word
"should" used on CLtL p.439 is covered by the discussion of "must" on
CLtL p.6, then right now this "is an error" rather than "signals an
error." Also, the specification that COMPILE is a no-op if called with
one argument and the symbol's definition is already compiled appears to
be a change from CLtL, although CLtL is so ambiguous it's hard to be
sure.
Unless there are reasons that these changes to COMPILE must be
incorporated into this proposal, I think it would be better to deal with
them as a separate proposal. For this proposal, I suggest confining the
discussion to how COMPILE defaults its second argument. I would say
that if the second argument is not supplied, the first argument "should"
be a symbol that is FBOUNDP and for which the implementation is able to
reconstruct the lambda-expression corresponding to its definition. So
the only change from CLtL would be to change "a definition that is a
lambda-expression" to "a definition from which the implementation is
able to reconstruct a lambda-expression". Possibly we should try to state
some necessary conditions under which the implementation is required to
be able to recover the lambda-expression. Possibly we shouldn't; this
only points out the inherent uselessness of 1-argument COMPILE in
portable programs.
Alternatively, we could take the coward's way out and make both
arguments to COMPILE be required, or, even better, make COMPILE take
only one argument, which must be a lambda expression, and neither read
nor write SYMBOL-FUNCTION.
∂11-May-87 1443 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 14:41:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137185; Mon 11-May-87 17:39:09 EDT
Date: Mon, 11 May 87 17:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-STREAM
Status: New issue, but easy to agree on
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
The book says that a stream can be used as an argument and converted to
a pathname, but pathnames only name files, not other sources or sinks
of data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream
that is or was open to a file.
Rationale:
This is probably what the designers of Common Lisp intended.
This is the only thing that can be implemented without large changes to
the language such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since I didn't say "signals an error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: None.
Aesthetics: Makes language a little cleaner.
Discussion: None yet.
∂11-May-87 1502 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 15:02:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137213; Mon 11-May-87 18:01:19 EDT
Date: Mon, 11 May 87 18:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-SYMBOL
[Note that this is not the same issue as PATHNAME-STREAM]
Status: New issue
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417).
Category: INCOMPATIBLE CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a
pathname is expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected.
Rationale:
The feature of accepting a symbol was copied by Common Lisp from Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a symbol
here was that it did not have strings at all. However, the feature has been
long since removed from Zetalisp, since it was found to be a source of bugs
and not to be useful. I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a
table entry that was expected to exist and returned -false-. In systems
that accept symbols as pathnames, this causes a reference to a file named
"nil" on some perhaps unexpected directory.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.
Adoption Cost:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.
Benefits:
Pathname functions will be more consistent. In implementations that check
the type of this argument, program error checking will be improved.
Conversion Cost:
Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings.
Aesthetics: Improved by the change.
Discussion:
The only user feedback on this issue I've seen was a bug report that
MERGE-PATHNAMES was in error because it accepted symbols.
∂11-May-87 1803 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 18:03:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:02:25-EDT
Date: Mon, 11 May 1987 21:02 EDT
Message-ID: <FAHLMAN.12301642842.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987 18:01-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I favor PATHNAME-SYMBOL:NIL.
It would be nice if someone would undertake a complete review of the
pathname situation. Seems to me that many problems lurk in here. But
the desire for a comprehensive solution shouldn't prevent us from
patching things that need to be patched.
-- Scott
∂11-May-87 1807 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-STREAM
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 18:05:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:04:29-EDT
Date: Mon, 11 May 1987 21:04 EDT
Message-ID: <FAHLMAN.12301643218.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-STREAM
In-reply-to: Msg of 11 May 1987 17:39-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I favor PATHNAME-STREAM:FILES-ONLY.
-- Scott
∂11-May-87 1901 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 19:01:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137484; Mon 11-May-87 21:59:47 EDT
Date: Mon, 11 May 87 21:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511215932.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
Status: Revised after discussion
Problem Description:
CLtL says that only keyword symbols can be used as non-positional argument
names in &key parameter specifiers.
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL.
Rationale:
As Common Lisp is currently defined, if someone wants to define a function
that accepts named (rather than positional) arguments whose names are
symbols in packages other than the KEYWORD package, they cannot use &KEY.
Instead, they have to duplicate the &KEY mechanism using &REST, GETF,
and (if they want error checking of argument names) DO. This suggests that
the restriction of &key to only keyword symbols is arbitrary and unnecessary.
Note that the "rationale" box on p.62 of Common Lisp: the Language is an
argument in favor of requiring non-positional argument names to be symbols,
and not allowing numbers, but does not speak to the issue of whether or not
those symbols should be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword symbols
arises when the set of non-positional arguments accepted by a function is
the union of the sets of non-positional arguments accepted by several other
functions, rather than being enumerated in a single place. In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability is
the draft proposal for an object-oriented programming standard. It will
have generic functions that accept non-positional arguments and pass them on
to one or more applicable methods, with each method defining its own set of
arguments that it is interested in. If this proposal is not adopted, either
the non-positional argument names will be required to be keywords, which
will require the methods to have non-modular knowledge of each other in
order to avoid name clashes, or the methods will have to be defined with an
ad hoc mechanism that duplicates the essential functionality of &key but
removes the restriction.
A second example of a Common Lisp application that requires this capability
is private communication channels between functions. Suppose a public
routine MAKE-FOO needs to accept arbitrary keywords from the caller and
passes those keywords along to an internal routine using keywords of its
own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would override
some keyword in keyword-value-pairs, since the only way that could happen is
if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user was
programming explicitly in the FOOLAND package, either of which is an implicit
admission of willingness to violate FOOLAND's modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in understanding
the impact of the proposal.
Change wording which refers to non-positional arguments as being introduced
by keyword symbols to simply refer to those arguments being introduced by
symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
Also, the word "keyword" in the first complete sentence on p.62 would
be changed to "symbol" for similar reasons.
Add extra wording on p.60 to explain that by convention keyword symbols
are normally used as non-positional argument names, and that all functions
built into the Common Lisp language follow that convention. A language
manual might or might not choose to describe the circumstances in which
it is appropriate not to follow this convention.
Add examples to illustrate this behavior. For example, on p.64 the
following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the restriction
that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a keyword
argument name, but allow all non-NIL symbols. (One Symbolics version that
was checked had this bug.)
Adoption Cost:
No existing programs will stop working. Some implementors might have to
rearrange their error checking slightly, but it should be very easy.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
Benefits:
This will help with the object-oriented programming standard, among other
things.
Conversion Cost:
None.
Aesthetics:
There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.
In any case, users who do not want to use the extended functionality
can generally avoid it.
Discussion:
Moon generated the original version of this proposal and supports it.
He thinks that if Common Lisp truly has a restriction that only keyword
symbols can be used as keyword names in calls to functions that take
keyword arguments, it will be more difficult to come up with an
object-oriented programming standard that fits within Common Lisp.
Pitman supports this proposal.
There was some question in the committee about whether the rationale
for the proposal was believable. I hope this version of the proposal
has resolved any doubts.
∂11-May-87 1907 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 19:07:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137493; Mon 11-May-87 22:05:42 EDT
Date: Mon, 11 May 87 22:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301642842.BABYL@C.CS.CMU.EDU>
Message-ID: <870511220522.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 11 May 1987 21:02 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I favor PATHNAME-SYMBOL:NIL.
To avoid any confusion: do you mean PATHNAME-SYMBOL:NO, or is
PATHNAME-SYMBOL:NIL a different proposal?
∂11-May-87 1940 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 19:40:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 22:39:37-EDT
Date: Mon, 11 May 1987 22:39 EDT
Message-ID: <FAHLMAN.12301660525.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987 22:05-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Clarification:
I favor PATHNAME-SYMBOL:NO.
-- Scott
∂12-May-87 0728 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 07:28:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 12 May 87 10:27:27-EDT
Date: Tue, 12 May 1987 10:27 EDT
Message-ID: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: Msg of 11 May 1987 21:59-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.
To prevent confusion, thr proposal should address the lambda-list syntax
explicitly. In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may noit be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.
If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls. The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list. Note that the variable must not be a constant, but that the
keyword-indicator may be.
Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.
One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator. Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user. If it screws some current implementations, that's
another (weak) reason to disallow this. I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".
-- Scott
∂12-May-87 0930 Gregor.pa@Xerox.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 09:30:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 87 09:26:41 PDT
Date: 12 May 87 09:24 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 11 May 87 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <870512-092641-3405@Xerox>
I support KEYWORD-ARGUMENT-NAME-PACKAGE:ANY.
∂12-May-87 1158 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 11:58:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138111; Tue 12-May-87 14:56:28 EDT
Date: Tue, 12 May 87 14:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Message-ID: <870512145619.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 12 May 1987 10:27 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.
Thanks.
To prevent confusion, thr proposal should address the lambda-list syntax
explicitly. In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may not be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.
I was using "non-positional-argument-name" where you used "keyword-indicator".
We have to do something about the terminology. I like "argument name" a little
better than "keyword indicator", although the former has the problem that people
might confuse it with "parameter name", since experience has shown that it's
virtually impossible for anyone to remember which are the arguments and which
are the parameters.
If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls. The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list. Note that the variable must not be a constant, but that the
keyword-indicator may be.
I agree with this, except that the syntax actually has two parentheses,
i.e. ((keyword-indicator variable)), to distinguish it from (variable default).
Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.
We can take "lambda-list-keywords", which aren't "keyword-symbols" either,
as a precedent.
One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator. Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user. If it screws some current implementations, that's
another (weak) reason to disallow this. I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".
I don't care about NIL being allowed or disallowed. As a language
designer, it seems like a weird restriction to disallow it, even though
there is no earthly reason to use it. As a commercial vendor, I won't
complain if we don't have to fix the bug that we currently disallow it.
I'll defer to anyone who has a strong opinion about this.
∂12-May-87 1258 gls@Think.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 12:57:56 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 15:59:54 EDT
Date: Tue, 12 May 87 15:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Fahlman@c.cs.cmu.edu, CL-Cleanup@sail.stanford.edu
In-Reply-To: <FAHLMAN.12299221539.BABYL@C.CS.CMU.EDU>
Message-Id: <870512155947.2.GLS@BOETHIUS.THINK.COM>
Date: Sat, 2 May 1987 15:21 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
...
I would like to encourage KMP to go ahead with a separate proposal for
ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it). Given that, I
think a version of POSITION that returns a single number for arrays is
probably the way to go, and users can then turn this into a subscript
list if they like. I have a mild aversion to getting a list from some
function that has heretofore always returned a number or NIL.
In this instance, note that a NIL result could be confused with an
empty list of subscripts, the natural result in the case of a
zero-dimensional array.
--Guy
∂12-May-87 1430 gls@Think.COM Issue: FUNCTION-TYPE (version 3)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:29:52 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:31:34 EDT
Date: Tue, 12 May 87 17:31 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-Id: <870512173129.7.GLS@BOETHIUS.THINK.COM>
I support FUNCTION-TYPE:REDEFINE.
∂12-May-87 1456 gls@Think.COM Issue: PATHNAME-SYMBOL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:56:02 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:58:18 EDT
Date: Tue, 12 May 87 17:58 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175812.2.GLS@BOETHIUS.THINK.COM>
I favor PATHNAME-SYMBOL:NO.
∂12-May-87 1457 gls@Think.COM Issue: PATHNAME-STREAM
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:56:55 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:59:14 EDT
Date: Tue, 12 May 87 17:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175910.3.GLS@BOETHIUS.THINK.COM>
I favor PATHNAME-STREAM:FILES-ONLY.
∂12-May-87 2104 Moon@STONY-BROOK.SCRC.Symbolics.COM [RAM: exiting from unwind protects]
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 21:04:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138596; Wed 13-May-87 00:02:53 EDT
Date: Wed, 13 May 87 00:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [RAM: exiting from unwind protects]
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Message-ID: <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 10 May 1987 14:54 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I find the following pretty persuasive...
I don't. Actually it seems to be mostly irrelevant to the issue at
hand. Here's some commentary on it. Feel free to show this to RAM if
you wish.
Date: Saturday, 2 May 1987 11:16-EDT
From: Rob MacLachlan <RAM>
I don't really agree with Moon about this thing. I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug". Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion. After a while I got bored of
trying to throw out of the break loop, and I quit.
If I had really been doing anything, I could always have skipped over
the losing frame using debug-return. Environment problems can have
environment solutions.
I don't know what debug-return is (presumably something in the Spice
Lisp environment). Unless it's something that bypasses unwind-protect
and deliberately doesn't evaluate the cleanup forms, I don't think it
solves the problem. However, I agree that environment problems can have
environment solutions, and I think the issue is to make sure that the
language doesn't forbid the environment from solving this by trying to
enforce a particular semantics for the pathological construct, instead
of having it be an error.
In any case, I could have saved work I was
doing from the break loop. This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water. What happened the last time you did
(makunbound '*terminal-io*)?
The second paragraph on p.329 appears to say that it is invalid for a
portable program to do that. What I am arguing for is a similar
restriction on portable programs doing the similar thing with
unwind-protect and throw. So I think this example actually supports my
position.
In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain. It seems that Moon has already introduced
three new things into the language:
1] The concept of "throwing out of an unwind protect cleanup". When
are you in an unwind protect? What does it mean to throw out of
it? Does this apply to lexical exits too? Does this signal an
error?
(block block
(unwind-protect <foo>
(return-from block)))
Does this?
(unwind-protect <foo>
(block block
(return-from block)))
Most of this would be answered by re-reading the relevant proposal to
the cleanup committee (are these archived someplace public?), which
was not written by me. I agree that we need a better-written version
of that proposal that is easier to understand and less ambiguous. The
one I am looking at is
Message-ID: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Edit history: Revision 1 by KMP 02/27/87
My only contribution to the discussion was
in the message <870423020745.9.MOON@EUPHRATES.SCRC.Symbolics.COM>.
Here are some relevant excerpts from the referenced proposal:
If a non-local return is done while in the cleanup form of an
UNWIND-PROTECT, the behavior is not always well-defined.
There are three basic cases:
...
1. Transfer to a point inside the point to which control
would have transferred.
and what I proposed in answer to this was to do one of three
things in case 1, transfer to a point inside the point to
which control would have transferred.
1. wimp out and say it "is an error"
2. signal an error
3. resume the original throw, just as if the cleanup handler had
exited normally.
I prefer signalling an error, because I firmly believe that the program
is ill-formed.
Note that I have not introduced any new concepts here. I don't think
the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT proposal introduced new
concepts either; it just made explicit reference to concepts that
were already in Common Lisp. The argument that these concepts make
the language definition too complex seems to be an argument that the
language definition should not attempt to define the semantics of throwing
precisely.
2] The concept of errors that aren't errors, which we need so that
users can't screw themselves with this feature no matter how hard
they try.
Last time I read the "error proposal" it included this concept. I don't
think I invented it, I just borrowed it from there while writing up the
discussion of throw vs. unwind-protect. Certainly in the absence of the
error proposal this concept is not introduced into the language, since the
language currently does not contain an IGNORE-ERRORS construct, nor any
other construct that is sensitive to the issue.
3] The implicit requirement that an implementation have some exit
mechanism other than throw so that it can unwind out of cleanup
forms even if the user can't. What does the system do when you
are running in an unwind protect and the user types an interrupt?
In fact, it seems that Moon is being inconsistent here, since he
has already assumed that interrupts do throw. If the user
interrupts when running in a cleanup do you signal an error, and
then signal an error whenever the user tries to abort out of the
debugger?
All of point 3 appears to be a misunderstanding of what was being
discussed and proposed. "Transfer to a point inside the point to which
control would have transferred" is irrelevant to "the user types an
interrupt" (which I take to mean something like Maclisp's control-X
and control-G, i.e. abort the program and return to a read-eval-print
loop) since those would be transfers to a point outside of, or equal to,
any throw currently in progress.
If I had ever been screwed by this, I would think differently.
The inside-Symbolics component of this discussion originated with a
customer being screwed by this.
I'm
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups. There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
error.
I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form.
Nobody ever proposed anything different as far as I am aware.
Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.
The issue is actually what happens you nest throws (throughout this
discussion "throw" has been understood to include all non-local exits,
not only the THROW function). Thus the marker in question is "in throw",
not "in an unwind protect cleanup".
Yes, the dynamic state of a program that is throwing would need to
include an indication of where it was throwing to if we were to adopt
the proposal that misnested throws signal an error or the proposal that
they resume the outer throw. In the "is an error" case, there are no
requirements on the implementation, and the requirement is only that
portable programs cannot assume any particular behavior. However, I
can't imagine an implementation of throw that does -not- remember in its
dynamic state where it's going to throw to when it finishes evaluating
some unwind-protect cleanup forms.
To get back to earth after all this lofty flaming, remember that the
specific case mentioned in the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
proposal was
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
and the question is: what does the THROW to BAR do? One possible answer
that many people seemed to favor is it throws to BAR and the throw to
FOO never happens. The answer I prefer is that this is not a valid
Common Lisp program. Does this make the issue clear?
∂12-May-87 2124 Moon@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 21:24:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138606; Wed 13-May-87 00:23:14 EDT
Date: Wed, 13 May 87 00:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870513002305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Observation: some of the discussion appears to be assuming that
someone is proposing that
(position 3 #2a((0 1 2)(3 4 5))) => (1 0)
As far as I can tell no one is proposing that. My reading of
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
is that it proposes
(position 3 #2a((0 1 2)(3 4 5))) => 3
and the other two options propose that it remains an error.
Vote: I mildly favor SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED as
being the least confusing to users, although either of the other two
proposals would be okay with me: if there is strong support for them,
I won't expend energy resisting it.
∂13-May-87 0012 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870513031041.0.KMP@TSUKUBA.SCRC.Symbolics.COM>
While I'm sympathetic to this proposal in some form, I can't support
it as currently drafted.
My main problem is that it tries to clarify too many things. The question of
what is a function is logically distinct from that of what may go in the
function cell. I am very excited about clarifying the type issues, but very
nervous about changing what can go in the function cell.
Here are my notes on the proposal...
* I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
the meaning and could provoke useless debate about what the difference
might be between a function and a closure; currently CL has no such
formal distinction.
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.
* "behavior" is spelled "behvior" in one place.
* I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
synonymous. Please cite a page reference that suggests they are allowed
to differ. I could not find a definition of the FUNCTION type specifier
when I looked just now.
* In item 3 of proposal, I'd say "the text of their description" to be
completely clear. To me, the descriptions are the abstract entities
which you've just noted don't need change.
* Items 4 & 5 are a major incompatibility that I would like to see proposed
and discussed separately so as not to bog down the type issues which this
proposal should be about. Macsyma, for example, makes considerable use
of symbols and lambda expressions in the function cell. Making sure it
would be happy with this clause would be very non-trivial.
For now, I would leave this essentially as you left APPLY, pending a
separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
return things which are non-functions if those objects can be coerced to
functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
and the value later retrieved will be the given object (not a coerced
form of it), though obviously internally some encapsulation may want to
go on for stock hardware to make function calling fast.
* At the in-person meeting at Xerox in March, I suggested that COMPILE
should not complain if it gets an already-compiled thing, and someone
pointed out that this could be bad because some users might be wanting
recompilation and others might want no action. I think we should consider
a better fix, like something that lets the user say explicitly what
action to take if the function is already compiled, but for now I would
leave this an error.
* The adoption cost does not mention STEP, TRACE, and ED. I think it should.
* The benefits section should flush the reference to Lisp1, since the only
criterion for being a Lisp-1 is that you have a unified namespace. In
fact, this is not properly related to that and mentioning Lisp1 may
provoke unnecessary worry. It is adequate to say it makes things more
like Scheme.
* I believe the conversion cost is potentially much greater than you
have estimated unless you move items 4 & 5 to another proposal.
The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
important consequences to do with the inheritance of new definitions of
BAR if it is later defined. I think that some people exploit this a lot
and it may not always be easy to detect.
The impact on home-grown steppers, trace and advise facilities, and other
functions which manipulate the contents of the function cell has also been
underplayed.
Please don't let these comments get you down. It's clear that a lot of work
has gone into this and I'm hopeful that it will be resolved successfully.
I just want to keep the decision process as unencumbered as possible and
right now it's just too hard for me to reason clearly about the overall
impact of such a sweeping proposal.
-kmp
∂13-May-87 0914 RPG FUNCTION-TYPE and Archives
To: cl-cleanup@SAIL.STANFORD.EDU
First, the archives for CL-cleanup are in clclea.msg[com,lsp].
However, this archive was separated out from the main Common-Lisp
archive only recently.
Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
I favor a much stronger change, and this proposal is just barely above
the level of acceptability to me.
KMP wonders
`` I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
synonymous. Please cite a page reference that suggests they are allowed
to differ. I could not find a definition of the FUNCTION type specifier
when I looked just now.''
The suggestion is on the same pages that allows the following two to
differ:
(let ((x '(or to-be (not to-be))))
(assert `(is-a question ,x)))
``To be or not to be: That is the question.''
KMP's third sentence is the answer: FUNCTION is a type name symbol
that corresponds to no type, and therefore (typep x 'function) is
not defined. This is what this proposal attempts to remedy.
However, to be slightly more serious, I am disturbed to always read
that Common Lisp must do this, that, or the other thing because otherwise
the effort to keep Macsyma up to date will suffer, or that the reason that
some feature must continue to exist is because it is reflected in
Macsyma usage. I like Macsyma as well as the next guy, but not enough to
kill a language to keep its code legal.
-rpg-
∂13-May-87 1133 @ALLEGHENY.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM FUNCTION-TYPE, archives, and Macsyma
Received: from [192.10.41.45] by SAIL.STANFORD.EDU with TCP; 13 May 87 11:33:01 PDT
Date: Wed, 13 May 87 14:23 EDT
From: KMP@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@QUABBIN.SCRC.Symbolics.COM
Subject: FUNCTION-TYPE, archives, and Macsyma
To: RPG@SAIL.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870513142303.6.FILE-SERVER@ALLEGHENY.SCRC.Symbolics.COM>
I spent well over a year converting Macsyma to what I believe is a good
faith reading of CLtL. At the outset, I was as tired as anyone of its
odd little needs that were unwritten parts of various languages and that
had to be supported only out of fear of breaking Macsyma.
I am trying to invoke no such fear now. Indeed, I don't even work for the
Macsyma project any more. I am sure that those who do work for it are
willing to do reasonable work to upgrade Macsyma into the next generation
Lisp.
However, those people (whoever they may be when it finally happens; my
grandchildren, I fear) will need to be able to adequately estimae the
impact of the various changes which we have made. And we ourselves must
adequately estimate the impact so that we can know how much work we are
asking people to absorb.
I said several times in my message that I might be willing to go along
with this change. I am not trying to "kill a language" as you put it.
I just want us to be honest. And when I read the text in this proposal
that said "... attempts to minimize the impact on user code ... the
only impact should be a change in the operation of certain type predicates
... relatively easy to find and fix" I knew we were not being honest.
The changes we're proposing may be good ones. They will not all be easy
to find and fix.
I do think that the part which simply involves types is fairly
non-controversial. I would like to see it separated so we can agree that
it is and leave a smaller issue to worry about.
∂13-May-87 1626 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE and Archives
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 16:25:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139430; Wed 13-May-87 19:24:13 EDT
Date: Wed, 13 May 87 19:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE and Archives
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 13 May 87 12:14 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870513192404.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 May 87 0914 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
First, the archives for CL-cleanup are in clclea.msg[com,lsp].
However, this archive was separated out from the main Common-Lisp
archive only recently.
[Second part deleted]
This is very useful, but if this was in answer to my question of yesterday
about archiving, I was actually asking a different question. I was wondering
if the current versions of the various proposals are archived somewhere,
such that one could retrieve a single proposal without first wading through
a bunch of mail. This might be a directory with each proposal in a separate
file, for example.
∂13-May-87 2121 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 May 87 21:21:16 PDT
Received: by navajo.stanford.edu; Wed, 13 May 87 21:18:45 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01380; Wed, 13 May 87 20:01:41 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03441; Wed, 13 May 87 20:03:04 PDT
Date: Wed, 13 May 87 20:03:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705140303.AA03441@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 13 May 87 00:02 EDT <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
Subject: looping in unwind-protect cleanups
I tend to agree with you that looping caused by UWP cleanup forms throwing
back through the same cleanup forms is a serious error; and that this
situation not only ought to be "signalled" as an error, but also ought to
be recuperable (from the debugger, I suppose). However, one or two loose
ends need to be cleared up. You mention the example from the original
proposal:
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
and you use the phrase "... this is not a valid Common Lisp program."
I have trouble with that characterization, since it seems to imply
some mechanically checkable property of programs. The "serious error"
mentioned above is a dynamic condition, which could be caused by other
programs that are not so clearly analyzable. For example, consider just
removing the (THROW 'BAR 4) out of the lexical context:
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(DO-A-BIT-OF-WORK)
(PRINT 'XXX))))
(DEFUN DO-A-BIT-OF-WORK ()
(UNLESS (WINNINGP)
(THROW 'BAR 4)))
I think you see how this could be extended to produce an example that could
not be mechanically proven invalid by the UWP-non-local-exit criterion,
even though it would get into the disastrous loop.
How about this characterization of the problem: for a given process, the
unwind-protect cleanup forms should be viewed as non-reentrant code. An
attempt to execute such code reentrantly will signal an error, which will
probably enter the debugger (and entering the debugger won't, by itself,
cause another throw, so there is no fear of infinite looping from this
step). In such a case, the user should have the choice of continuing with
the re-entrant invocation, or of doing an "abort" which skips doing the
signalled UWP frame's cleanups. In the first case, he may want to "try
again" at the cleanups, because it just might be that they were entered
"re-entrantly" only because he interrupted in the middle of some cleanups,
and then asked the debugger to "abort to toplevel"; or maybe entering the
"embrace" depends on some global data which he has just "fixed". In the
second case, he may recognize the "deadly embrace" as hopeless, and simply
wish to punt out of it.
There is some concern about "hairing up" the UWP/THROW mechanisms. I
don't believe that this approach, or *** ones like it *** (which were
alluded to in previous messages) is really all that complex.
Implementationally, it would seem to require at most:
(1) For each UWP frame, the "cleanup forms" have an associated lock
(possibly a per-process lock) that is acquired upon entry [and
released upon exit?]. Failure to acquire the lock signals the
re-entrancy error. The acquisition/release time could hardly
be more than a few memory cycles time, and hence won't be a serious
slowdown for THROWing.
(2) The low-level part of THROW would admit a "skip me" argument, so
that it could be told which UWP/CATCH frame to omit the cleanups
on [but not the lock releasings?]. Only one "skip me" is needed,
since nested "deadly embraces" could be undone one step at a time.
[In fact there really only could be one frame to "skip" -- the one
whose lock is already tied up.]
I don't mean to imply that this is the only, or the best, or even the
clearest implementation of such an idea; but I claim that non-re-entrancy
isn't all that deep a concept here. It's more to the point than saying
"non-interruptible" (which is wrong); and more succinct than some other
characterizations of how one might detect the "deadly embrace".
-- JonL --
∂13-May-87 2158 Moon@STONY-BROOK.SCRC.Symbolics.COM looping in unwind-protect cleanups
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 21:58:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139634; Thu 14-May-87 00:57:23 EDT
Date: Thu, 14 May 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8705140303.AA03441@bhopal.edsel.uucp>
Message-ID: <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 13 May 87 20:03:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
...you use the phrase "... this is not a valid Common Lisp program."
I have trouble with that characterization, since it seems to imply
some mechanically checkable property of programs.
I didn't mean to imply that.
...I think you see how this could be extended to produce an example that could
not be mechanically proven invalid by the UWP-non-local-exit criterion,
even though it would get into the disastrous loop.
Sure. If you give me a few hours, I will mail you examples of programs
in Common Lisp, Ada, and Basic the determination of whose validity in
their respective languages is equivalent to the halting problem. The
basic plan is to write a program where it cannot be mechanically proven
whether an array subscript is out of bounds.
....Implementationally, it would seem to require at most:
(1) For each UWP frame, the "cleanup forms" have an associated lock ....
This is rather overcomplicated, so let me tell you how the versions of
Symbolics systems that implement my proposed checking do it. None of
these are released yet. This is from memory, I didn't write the code.
1. Every catch (including ones generated internally by tagbody and block
when nonlocal exits via go, return, or return-from are happening) contains
a validity bit, which is initially 1.
2. When throw plans to throw past a catch, it sets its validity bit to 0.
This happens after throw finds the target catch (since Common Lisp says if
there is no matching catch, the error is signalled in the dynamic environment
of the throw), and before throw starts removing state from the stack and
evaluating cleanup forms. Here throw includes nonlocal go, return, and
return-from along with certain debugger commands.
3. An attempt to throw to a catch whose validity bit is 0 signals an error
that isn't caught by IGNORE-ERRORS.
4. The error in 3 is implemented by the Common Lisp function BREAK.
5. When throw evaluates an unwind-protect cleanup form, it first removes
it from the list of such forms, so that if you throw again it won't be
evaluated again. (I'm pretty sure that a close reading of CLtL shows
that this is required.)
Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.
∂14-May-87 1039 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 10:39:24 PDT
Received: by navajo.stanford.edu; Thu, 14 May 87 10:36:48 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA03537; Thu, 14 May 87 10:23:10 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03960; Thu, 14 May 87 10:24:36 PDT
Date: Thu, 14 May 87 10:24:36 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705141724.AA03960@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 14 May 87 00:57 EDT <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups
Re: . . . let me tell you how the versions of
Symbolics systems that implement my proposed checking do it. None of
these are released yet. This is from memory, I didn't write the code.
. . .
Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.
A lock is effectively 1 bit per catch, and by storeing it in the catch
frame, it is process-specific; lock-acquisition would be done in THROW,
and is very low overhead. I suspect these two proposed implementations
are isomorphic at a fundamental level, with your "validity bit" replaceing
my "lock".
The only thing that seems a bit peculiar in your review of the new Symbolics
code is that the error signalled by "failure to acquire the lock" has to be
treated specially (not caught by IGNORE-ERRORS, goes directly to BREAK,
"does not pass GO, lands in jail", whatever). Maybe that is the reason RAM
and some others were so upset by the original proposal. I think I see the
point of the special handling; but I don't like the singularity.
-- JonL --
∂14-May-87 1046 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 10:45:08 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140100; Thu 14-May-87 13:43:48 EDT
Date: Thu, 14 May 87 13:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134332.1.KMP@TSUKUBA.SCRC.Symbolics.COM>
I support PATHNAME-SYMBOL:NO, but I have the following comments:
* Please change the reference to filename "nil" to filename "NIL"
since (STRING NIL) returns "NIL" and not "nil". This is a minor
point, but I think worth doing.
* Note that the biggest impact of this change on users is that
they will not be able to say (LOAD'FOO) which they commonly type
interactively to mean (LOAD "FOO"). One advantage, of course, is
that in case-sensitive file systems, people won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not
found. Still, I think the fact that we're going to make it an
error for people to type (LOAD 'FOO) is worth documenting as part
of the cost of this proposal so that no one ends up surprised.
∂14-May-87 1051 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 10:50:32 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140111; Thu 14-May-87 13:49:01 EDT
Date: Thu, 14 May 87 13:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134846.2.KMP@TSUKUBA.SCRC.Symbolics.COM>
I support PATHNAME-STREAM:FILES-ONLY.
Since string-streams are non-file streams that CL programmers
will be familiar with, it might be worth mentioning them explicitly
in the proposal as an example of something for which the indicated
functions do not have to work.
∂15-May-87 2144 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 May 87 21:44:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141562; Sat 16-May-87 00:44:03 EDT
Date: Sat, 16 May 87 00:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>,
<870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<870428-220403-2039@Xerox>,
<870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<192793.870429.JAR@AI.AI.MIT.EDU>,
<8704292330.AA13102@bhopal.edsel.com>,
<870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<193127.870429.JAR@AI.AI.MIT.EDU>,
<8704300644.AA13625@bhopal.edsel.com>,
<8704302311.AA01123@bhopal.edsel.com>,
<193809.870430.JAR@AI.AI.MIT.EDU>,
<8705012012.AA00639@bhopal.edsel.uucp>,
<FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>,
<194629.870502.JAR@AI.AI.MIT.EDU>,
<FAHLMAN.12299293460.BABYL@C.CS.CMU.EDU>
Message-ID: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I finally found the time to read this huge pile of mail carefully and think
clearly about it. Here's my considered opinion, but before telling you
which proposal I support I'd like to clear away some underbrush. I
apologize for the 200 line length, but I can't make all the concepts
unambiguously clear with a briefer speech.
We speak of cells, which are conceptual locations that remember a value and
can be read and written. Sometimes these conceptual locations are
implemented by actual memory locations, and sometimes they aren't, but
that's an implementation detail and is irrelevant here. (Sometimes these
are called variables, but other times the word "variable" means something
else, so for the sake of clarity I'm not going to use the word "variable".)
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
Right now, Common Lisp has two kinds of binding: Lexical binding creates a
new local cell. Special binding saves the value of a global cell, gives it
a new value during the extent of the binding, and later restores the old
value. We know that special binding saves and restores because of what
other functions see when they read the cell. Please don't get confused
with issues of shallow-bound versus deep-bound implementation, which are
irrelevant here: I said cells are not the same thing as memory locations.
Note that I am carefully using different words for the two kinds of cells
from the words for the two kinds of binding; lack of differentiation here
has led to a lot of confusion, I think.
Right now, Common Lisp has a fairly complicated set of rules for how to
determine what cell is referenced when a program mentions a variable name.
(When I say "lexically free", I mean outside of all bindings of that name,
regardless of whether those bindings are special or lexical.)
1. If the reference is lexically free, use the global cell.
2. Otherwise, in the absence of a SPECIAL declaration use the cell that
was affected by the innermost binding; if that binding was special,
use the global cell; if it was lexical, use the local cell created
by that binding.
3. Otherwise, the SPECIAL declaration forces use of the global cell.
We certainly do not want to introduce a third kind of cell, because that
would lead to a great deal of confusion. Nor do we want to introduce a
third kind of binding. What we -are- trying to accomplish is to make the
primitive concepts orthogonally available. An example of a problem we have
right now that needs to be fixed is that there is no way to say that a name
is not misspelled without simultaneously saying that bindings of that name
should be special rather than lexical. These concepts should be available
as separate constructs.
There are four things that we would like to be able to proclaim about
a variable name (aside from TYPE):
- the default kind of binding if no declaration specifies which kind
- the name is not misspelled so don't warn about free references
- it is illegal to specially bind the global cell, because it is
a constant or because we want to optimize the performance of a
deep-binding implementation
- it is illegal to store into the global cell, because it is a constant
It is already possible in Common Lisp to proclaim all four of these things,
but some of them are mixed up with other concepts and not separately
available. Let's pick names for the four kinds of proclamations, and let's
also agree that any proclamation serves the "not misspelled" purpose. Let's
further agree that these four proclamations are mutually exclusive.
LEXICAL -- does nothing other than "not misspelled"
SPECIAL -- changes the default kind of binding from lexical to special
GLOBAL -- makes it illegal to specially bind the global cell
CONSTANT -- makes it illegal to store into the global cell
CONSTANT implies GLOBAL because special-binding is storing
SPECIAL exists now. LEXICAL is Rees's proposal. CONSTANT exists now
but only buried inside the DEFCONSTANT macro. GLOBAL exists now but
only when implied by DEFCONSTANT. I propose to make CONSTANT and
GLOBAL explicitly available.
It appears to be appropriate to make CONSTANT and GLOBAL proclamations
change the default kind of binding to "illegal", rather than leaving
it lexical.
Now we have to ask what these proclamations mean as declarations.
Let us agree that they have the same scoping rules as the SPECIAL
declaration, i.e. they can be attached to a binding and they can
also be wrapped around references, which they pervasively affect
until shadowed by the next declaration or binding.
LEXICAL attached to a binding forces the binding to be lexical even
if there is a SPECIAL, GLOBAL, or CONSTANT proclamation. LEXICAL
shadows the effect of a special binding on references; therefore we
must add another rule to the "complicated set":
4. Otherwise, a LEXICAL declaration forces use of the local cell
created by the innermost lexical binding of the name, or if there
is none, use of the global cell.
SPECIAL means the same as it has always meant in Common Lisp.
GLOBAL or CONSTANT attached to a binding makes the binding illegal.
GLOBAL or CONSTANT affects a reference by forcing it to use the global
cell, thus rule 3 in the "complicated set" must be modified to treat GLOBAL
and CONSTANT the same as SPECIAL. We could also just make GLOBAL and
CONSTANT illegal as declarations. Another idea would be to make CONSTANT
as a declaration allow you to create a new lexical constant. I'm going to
take the path of least addition to the language and make them illegal.
Note that PROCLAIM-LEXICAL:RESTRICTED conflates LEXICAL and GLOBAL, which
seems undesirable to me. We want to make each primitive concept separately
available.
Okay, so which proposal do I support? Well, I support a slight modification
of PROCLAIM-LEXICAL:GENERAL, which I will now explicate (text mostly
copied from Rees):
Proposal (PROCLAIM-LEXICAL:GENERAL+GLOBAL):
Introduce new declaration specifiers, LEXICAL, GLOBAL, and CONSTANT, which
are mutually exclusive with the SPECIAL declaration specifier. All four
may be used as proclamations; only SPECIAL and LEXICAL may be used as
declarations.
A name may be proclaimed only one of LEXICAL, SPECIAL, GLOBAL, or
CONSTANT. A name is said to be unproclaimed if it has not been
proclaimed to be any of these four.
A free reference or assignment to a name is an error if it is
unproclaimed and undeclared.
A LAMBDA-binding in the absence of a declaration or proclamation binds
the lexical variable.
SPECIAL proclamations and declarations behave as defined in CLtL.
LEXICAL proclamations have no effect other than to make the name
cease to be unproclaimed. LEXICAL declarations shadow all enclosing
declarations and proclamation of any of these four types. LEXICAL
declarations have the same scoping rules as SPECIAL declarations.
GLOBAL proclamations make it an error to bind the name.
CONSTANT proclamations make it an error to bind the name and an
error to assign to the name.
DEFCONSTANT is defined in terms of SETQ and the CONSTANT proclamation.
All keyword symbols are automatically proclaimed CONSTANT.
A free reference or assignment accesses the same value regardless
of the declaration or proclamation. This is called the global value.
SPECIAL binding alters the global value within its extent.
(Multiple process and multiple processor systems will have to make
their own definitions of the extent of a SPECIAL binding, as noted
on p.38 of CLtL--this proposal is not a proposal to standardize that.)
The preceding paragraph should be understood carefully. There is only
one global value for a name and it is used by all free references, all
free assignments, and all SPECIAL bindings.
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
Note that the second element of the list is different from
the value, 2, it would have in PROCLAIM-LEXICAL:GENERAL.
That is because the special binding of y changes the global
value to 4, and the declared-lexical reference to y accesses
the global value, since there is no surrounding lexical binding.
Cost of adopting change:
I believe this is the same as current practice as specified by CLtL,
except that all of the primitive concepts have been made visible instead
of being hidden inside other concepts. Compilers and interpreters
will need to support LEXICAL as a declaration.
Referencing or assigning to an unproclaimed and undeclared name
"is an error", not "signals an error", which allows but does not
require an implementation to issue a warning. This is a change from
current language but does not mandate a change from current practice.
Benefits:
LEXICAL proclamation enhances compatibility with Scheme.
GLOBAL proclamation allows more efficient deep-bound implementations
and enhances compatibility with Interlisp and VMLISP.
Cost of converting existing code:
None, it's upward compatible.
Aesthetics:
The "insidious and disgusting aspect" doesn't get any worse. Making
primitive concepts explicitly available can only enhance aesthetics.
Discussion:
Let's hear it!
∂16-May-87 0302 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 May 87 03:02:07 PDT
Received: by navajo.stanford.edu; Sat, 16 May 87 02:58:25 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA10964; Sat, 16 May 87 01:33:58 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA09180; Sat, 16 May 87 01:35:27 PDT
Date: Sat, 16 May 87 01:35:27 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705160835.AA09180@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 16 May 87 00:43 EDT <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
Your summary of the "proclamation" issue is excellent. It delineates all
the separate issues very well, and also it incorporates all the points I
have made in previous notes about these matters. So I for one would be
quite happy to see your revised proposal accepted.
-- JonL --
∂17-May-87 1447 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 14:47:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 17:46:49-EDT
Date: Sun, 17 May 1987 17:46 EDT
Message-ID: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 16 May 1987 00:43-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I think that Moon's analysis of this issue is right on the mark, and I
like his proposal except for two points:
First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one. We have to address
that, I think, and it is a moderately complex question.
It seems to me that we want to allow a variable to be re-proclaimed for
two reasons: to correct proclmations issued in error by the user,
without having to kill off the Lisp and start over, and to make it
easier to merge programs written by two different programmers. (The
latter reason may be bogus -- these guys shouldn't be in the same
package anyway -- but there are times when a quick-and-dirty fix is
extremely handy.) On that other hand, we want the compiler to be able
to wire certain things in tight as a result of these proclamations, so
we need to make clear that if you proclaim something to be GLOBAL,
compile some code, then proclaim it to be SPECIAL and then compile some
more code the rebinds this variable, you may not get what you expect.
Same with unconstantifying a constant.
If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
-- Scott
∂17-May-87 1931 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 1987 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Cc: fahlman@C.CS.CMU.EDU
Subject: Issue: FUNCTION-TYPE (version 3)
In-reply-to: Msg of 13 May 1987 03:10-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
In reply to: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>.
My main problem is that it tries to clarify too many things.
I agree with Moon that Compile can be split out of this proposal and
dealt with separately. However, I feel that the other issues really
have to be dealt with all at once. The issue of what constitutes the
FUNCTION type and whether function definitions have to be functions in
whatever sense we define are closely interconnected. We'll ahve to
solve the latter issue sooner or later, so let's try to do it now.
* I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
the meaning and could provoke useless debate about what the difference
might be between a function and a closure; currently CL has no such
formal distinction.
No problem with eliminating any mention of this. It was just a "for
instance" anyway.
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.
One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P. That's what I proposed in version 3. The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example. Then there's the question of whether closures are, or can be,
a separate subtype. In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment. However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.
In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
* In item 3 of proposal, I'd say "the text of their description" to be
completely clear. To me, the descriptions are the abstract entities
which you've just noted don't need change.
I disagree with this use of "description", but there's no point in
arguing epistemology here. I'll change the wording.
Macsyma, for example, makes considerable use
of symbols and lambda expressions in the function cell. Making sure it
would be happy with this clause would be very non-trivial.
I don't understand this. If your code expects to put random symbols and
lambda lists into function cells and to get them back later, unchanged,
this is not portable Common Lisp. At least, the manual is so vague in
this area that you'd better not count on anything of this sort being
portable. PCL was storing symbols in symbol-function cells for awhile,
but this broke lots of implementations and they finally gave up on this.
For now, I would leave this essentially as you left APPLY, pending a
separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
return things which are non-functions if those objects can be coerced to
functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
and the value later retrieved will be the given object (not a coerced
form of it), though obviously internally some encapsulation may want to
go on for stock hardware to make function calling fast.
I know of several Common Lisps in which this is not the status quo. So
either way we clarify this, it is an incompatible change for someone. I
hate to see us take a step backwards here, just to make Macsyma more
portable than it currently is.
I agree that we should make a bit more of this issue in the "conversion
costs" section -- truth in advertising -- but I think that saying that a
function definition must be a function is an important part of the
rationalization we are trying to achieve.
Would it make life any easier for Macsyma (and other programs with this
same problem, if any exist) if we were to add a function that extracts
the lambda expression from a function if the function is uncompiled and
is not a closure (in the stronger sense mentioned above)? In some
implementations this might be EQ or at least EQUAL to the original
Lambda, but in others it might have been macro-expanded or altered in
some way that preserves its essential behavior. We could call the
function EXTRACT-LAMBDA-EXPRESSION or something like that.
* At the in-person meeting at Xerox in March, I suggested that COMPILE
should not complain if it gets an already-compiled thing, and someone
pointed out that this could be bad because some users might be wanting
recompilation and others might want no action. I think we should consider
a better fix, like something that lets the user say explicitly what
action to take if the function is already compiled, but for now I would
leave this an error.
How about if we just adopt your earlier proposal: if the function is
already compiled, COMPILE is a no-op that returns the NAME.
* The adoption cost does not mention STEP, TRACE, and ED. I think
it should.
OK.
* The benefits section should flush the reference to Lisp1, since the only
criterion for being a Lisp-1 is that you have a unified namespace. In
fact, this is not properly related to that and mentioning Lisp1 may
provoke unnecessary worry. It is adequate to say it makes things more
like Scheme.
OK.
* I believe the conversion cost is potentially much greater than you
have estimated unless you move items 4 & 5 to another proposal.
The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
important consequences to do with the inheritance of new definitions of
BAR if it is later defined. I think that some people exploit this a lot
and it may not always be easy to detect.
The impact on home-grown steppers, trace and advise facilities, and other
functions which manipulate the contents of the function cell has also been
underplayed.
Well, as I said, such code is currently not portable because nothing in
the book unambiguously requires that symbols and lambda expressions be
put into the SYMBOL-FUNCTION cell unchanged (or that such changes be
undone upon retrieval), and because many implementations currently do
not do this. So there's a cost either way we clarify this. Doing it
the way you suggest tends to put the burden on implementors rather than
on the maintainers of old code, but I still think it is a step
backwards.
-- Scott
∂17-May-87 1944 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE and Archives
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 19:42:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:42:14-EDT
Date: Sun, 17 May 1987 22:42 EDT
Message-ID: <FAHLMAN.12303233875.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE and Archives
In-reply-to: Msg of 13 May 1987 12:14-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
In reply to: Dick Gabriel <RPG at SAIL.STANFORD.EDU>.
Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
I favor a much stronger change, and this proposal is just barely above
the level of acceptability to me.
I assume that the "stronger proposal" you favor would require FUNCALL,
APPLY, and friends to accept only true functions.
I would go along with putting both options into the proposal we send to
X3J13 and let them vote on it. My guess is that the conservatives would
prevail, but I personally would favor the "stronger proposal". (That's
easy for me, because I have relatively little code to maintain.) It
might be worth a try -- maybe truth and beauty would win.
However, there's a chance that if we put forward two options, the whole
thing will bog down for a while. I wonder if it is worth the risk of
added delay.
-- Scott
∂18-May-87 1344 gls@Think.COM Issue: PROCLAIM-LEXICAL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 May 87 13:44:21 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 18 May 87 16:46:47 EDT
Date: Mon, 18 May 87 16:44 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870518164427.1.GLS@BOETHIUS.THINK.COM>
I am in agreement with everything Moon has said, except for the
following paragraph:
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
I believe this paragraph confuses the notions of extent and scope.
In the terminology of CLTL chapter 3, both kinds of cell have
indefinite extent (but the bindings of a global cell have dynamic
extent). The *names* used to refer to these cells have lexical
and <???> scope, respectively.
If this bit of language were to be cleaned up, I would favor something
like Moon's proposal.
--Guy
∂18-May-87 1529 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 15:29:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 142936; Mon 18-May-87 18:28:46 EDT
Date: Mon, 18 May 87 18:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870518164427.1.GLS@BOETHIUS.THINK.COM>
Message-ID: <870518182849.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 18 May 87 16:44 EDT
From: Guy Steele <gls@Think.COM>
I am in agreement with everything Moon has said, except for the
following paragraph:
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
I believe this paragraph confuses the notions of extent and scope.
Quite right. I must have meant to say "scope", but spazzed.
∂19-May-87 1316 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-NEGATIVE-PARAMETERS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 13:16:02 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143993; Tue 19-May-87 16:15:07 EDT
Date: Tue, 19 May 87 16:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-NEGATIVE-PARAMETERS
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303677629.BABYL@C.CS.CMU.EDU>
Message-ID: <870519161434.8.KMP@TSUKUBA.SCRC.Symbolics.COM>
[Removed Berman, Common-Lisp; added CL-Cleanup]
Date: Tue, 19 May 1987 15:19 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: 19 May 1987 14:38-EDT
From: Richard Berman <berman at vaxa.isi.edu>
... do you know what this should do?
(FORMAT NIL "~-1%")
... there seem to be a number of places in the format directives where
negative numbers would make no sense. I don't think that all of these
are explicitly flagged. This should probably be fixed up in the
standard, but until then it seems reasonable to assume non-negative
integers unless there's some obvious meaning for the negative case.
This would be a reasonable topic for us to address in CL-Cleanup.
I agree that a reasonable approach for the interim, and in fact in the
next edition of the manual, is to say that format parameters are assumed
to be non-negative integers except as specifically stated. Of course, we'll
need to specify clearly whether signalling an error or assuming 0 or whatever
is the right thing otherwise, and that should perhaps be done by someone who
has surveyed all the ops to determine the likely impact on typical code of
assuming 0, etc.
Cases where some implementations signal an error and others quietly ignore
the error are what drive developers of portable code nuts.
By the way, I note that this case is most important where the user has
written ~V%, since it's not statically detectable in that case that a problem
has arisen.
Obviously, someone should write this up as a formal proposal. I've picked
the issue name FORMAT-NEGATIVE-PARAMETERS above and this message can be used
to seed the proposal when someone has time to write it.
∂19-May-87 1739 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 17:39:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144321; Tue 19-May-87 20:38:25 EDT
Date: Tue, 19 May 87 20:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Message-ID: <870519203829.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 17 May 1987 17:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think I forgot to answer this, but if you're seeing it twice, I apologize.
I think that Moon's analysis of this issue is right on the mark, and I
like his proposal
Thanks.
except for two points:
First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC
CONSTANT, you mean.
can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one. We have to address
that, I think, and it is a moderately complex question.
I think this is an environment issue rather than a language issue.
....
If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
I think Rob's proposal would only tell us how to compile a program that
proclaims a variable one way inside a Lisp that proclaims it another way,
but not what happens when the result of that compilation is loaded into
that Lisp.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable.
Actually I just copied that from Rees.
The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human users?
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
True.
∂19-May-87 1801 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:01:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:00:27-EDT
Date: Tue, 19 May 1987 21:00 EDT
Message-ID: <FAHLMAN.12303739600.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 19 May 1987 20:38-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
OK, I think we agree here, more or less. I'd like to see some
indication in the proposal that this particular "is an error" is one
that many interpreters might choose to allow for the convenience of
programmers. Some people equate "is an error" with "don't do it" rather
than "don't depend on it across implementations".
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human
users?
Well, you're right in saying that "is an error" would be the right thing
if our only concern were portable programs. That's our main concern,
but not our only one. I would still like to be able to do a few typical
interpreter things in any Common Lisp, and this is one of them. So I am
strongly opposed to any proposal that says it is OK for (setq foo 27)
this issue doesn't affect portable
programs, but that's not the only concern we should deal with. I would
like to see
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
True.
∂19-May-87 1812 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:12:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:11:08-EDT
Date: Tue, 19 May 1987 21:10 EDT
Message-ID: <FAHLMAN.12303741560.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
Sorry, I hit the wrong key and shot that last message off before I was
done editing...
In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
OK, I think we agree that "is an error" would be the best thing here.
I'd like to see some indication in the proposal (maybe down in the
discussion part) that this particular "is an error" is one that some
interpreters might choose to tolerate (preferably with some warning) for
the convenience of interactive users. Some people equate "is an error"
with "don't do it" rather than "don't depend on it in portable code".
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human
users?
Well, you're right in saying that "is an error" would be the right thing
if our ONLY concern were portable programs. That's our main concern,
but not our only one. I would still like to be able to do a few typical
interpreter things in any legal Common Lisp, and this is one of those
things. So I am strongly opposed to any proposal that says it is OK for
(setq foo 27) not to work in some Common Lisp interpreters.
So I feel pretty strongly that my earlier formulation was the
best one: references and assignments of undeclared/unproclaimed
variables refer to the global cell, but leave the variable undeclared.
And compilers are allowed (not required) to warn about such references.
-- Scott
∂26-May-87 1431 Masinter.pa@Xerox.COM administrative
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 May 87 14:31:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 MAY 87 14:26:31 PDT
Date: 26 May 87 14:26 PDT
From: Masinter.pa@Xerox.COM
Subject: administrative
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870526-142631-1697@Xerox>
I've gotten way behind the last couple of weeks on my mail.
I hope we are not too late to mail out the proposals we have ready for
voting at X3J13. I'll try to get a summary out this week and revised
versions.
I have a separate file of mail on each proposal, where the latest
version of each proposal is generally a recent message. However, these
are not on an externally available file server. I started to try to keep
the latest version of each proposal in a separate file on a public
server, but it was a lot of work with no percieved benefit.
Right now, I'll just offer the service that if anyone needs the latest
version of something , send me a personal message and I will mail it
out. (This may seem inconsistent with my being behind in my mail, but
personal mail gets priority.)
If anyone has any revised versions of any of the open proposals they
want to submit for consideration at the next X3J13 meeting, this is the
week to get them in.
∂28-May-87 2233 JAR,KMP@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 May 87 22:32:46 PDT
Date: Fri, 29 May 87 01:34:10 EDT
From: JAR, KMP@AI.AI.MIT.EDU
Sender: JAR@AI.AI.MIT.EDU
Subject: Issue: PROCLAIM-LEXICAL
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <206630.870529.JAR@AI.AI.MIT.EDU>
We feel that the exposition preceding Moon's proposal contains some
assumptions which lead him to conclusions with which we're somewhat
uncomfortable.
Although the proposal is coherent and we don't think it's technically
unworkable, we're not really happy with the conceptual model of
special binding which it seems to presuppose.
Apparently, I (JAR) have been hacking denotational semantics so long
that the way that Lisp hackers think is now completely foreign
to me. Moon's notion of a "cell" feels very unnatural, for example.
Were I to write a Common Lisp EVAL in a less complicated language,
e.g. lambda calculus, Pascal, or Scheme, I would start as follows:
(defun eval (exp lexical-env dynamic-env store cont)
(cond ((symbolp exp)
...)
...))
In this notation, a DYNAMIC-ENV maps names to locations, and a STORE
(British word for memory) maps locations to values. This makes clear the
exact manner in which the "meaning" of a variable depends on the context
(dynamic, lexical, and prior side-effects) in which it occurs. It looks
like Moon's notion of a "cell" bundles these two mappings in some way,
but it's not completely clear how. It would be interesting to see how
Moon would write EVAL (using UNWIND-PROTECT perhaps?) in a language that
had no side effects or dynamic binding.
The intent here is not to convince anyone that some particular
model is right or wrong, but to point out that there's more than one
valid way of modeling all this. Moon's proposal follows neatly from
the exposition which precedes it, but since we're not happy with the
exposition, it's not surprising that we're not happy with the
proposal.
One particular point of contention: we're uneasy about Moon's suggestion
that binding a special variable can affect the evaluation of a lexical
variable. This is an example of how a bias toward a shallow-binding model
shows through.
These remarks are too brief and we expect to have more to say on
this later, but since Larry's probably making up a status report for
presentation to X3J13, and since the comments on Moon's proposal have
thus far been non-critical, we wanted to get it into the record that
we think there's more work to be done here.
∂29-May-87 2113 Masinter.pa@Xerox.COM barrage of mail coming
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:13:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:13:17 PDT
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
Subject: barrage of mail coming
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-211317-1248@Xerox>
Stay tuned for a barrage of mail; I've been trying to get the open
proposals into a form that we can ship. I will send out new copies of
several proposals where I've made minor (or in a few cases major) edits
to incorporate comments on this list.
You will get:
Revised versions of many of the proposals (at least up thru
PATHNAME-SYMBOL today)
A revised status report (ditto)
A ***BALLOT***. Most of the ballot items are of the form:
[ ] Release as is [ ] Comments follow in mail to cl-cleanup.
Most of this is just double checking to make sure that the silent
members of the committee really agree even if they haven't responded.
∂29-May-87 2114 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:14:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:13:54 PDT
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
Message-ID: <870529-211354-1250@Xerox>
Status: Minor edits for presentation. No disagreement in committee.
Ready for release? (use ballot).
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: Steele p.297
Category: Clarification
Edit history: Revision 1 by SEF, 18-Apr-87 (from Steele's list)
Revision 2 by Masinter (minor)
Problem Description:
The interaction of Adjust-Array and displacement is insufficiently
specified in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Suppose we are adjusting array A, which is perhaps displaced to B before
the Adjust-Array call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate. Additional elements of A
are taken from the :initial-element. The use of :initial-contents
causes all old contents to be discarded.
(2) A is not displaced before, but is displaced to C after. As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.
(3) A is displaced to B before the call, and is displaced to C after the
call. As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C). If
:displaced-index-offset is not specified in the Adjust-Array call, it
defaults to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element. However, the use of
:initial-contents causes all old contents to be discarded.
Note that if array X is displaced to array Y, and array Y is displaced
to array Z, and array Y is altered by Adjust-Array, array X must now
refer to the adjusted contents of Y. This means that an implementation
may not collapse the chain to make X refer to Z directly and forget that
the chain of reference passes through array Y. (Cacheing techniques are
of course permitted, as long as they preserve the semantics specified
here and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X. This error may be signalled
at the time of the adjustment, but this is not required.
Rationale:
This interaction must be clarified. This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here. Others
may do something random. [See discussion below.]
Adoption cost:
Some existing implementations may have to be changed, but adopting any
other model would be worse. Public-domain code implementing this model
is available from CMU.
Benefits:
Clarification of a situation that is currently not addressed by the
standard.
Conversion Cost:
This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works. Any
user code that cares about this issue probably already follows the
proposed model.
Discussion:
Discussed long ago on the Common Lisp mailing list. This proposal
attempts to capture the overall consensus that emerged at that time.
Moon: We [Symbolics] implement what is proposed, except for
(4) A is displaced to B before the call, but not displaced
afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional
elements
of A are taken from the :initial-element.
We never copy the contents of B in this case; all elements are taken
from the :initial-element.
Either behavior seems equally justifiable to me. One could say
"adjust-array never stores into the array if it ends up displaced" or
"adjust-array only preserves the elements of non-displaced arrays." I
have no information as to whether it matters to users.
∂29-May-87 2116 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:16:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:15:53 PDT
Date: 29 May 87 21:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue DEFVAR-INIT-TIME (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-211553-1257@Xerox>
Status: I worked over the wording on this one a little. Ready for
release?
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
29-Mar-87, Revision 2 by Masinter
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating the
form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
is not evaluated unless it is used; this fact is useful if evaluation of
the INITIAL-VALUE form does something expensive like create a large data
structure.''
At least one implementation interpreted the "unless it is used" to mean
"unless the variable is used" rather than "unless the initial-value is
to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
interpreted as a kind of lazy initialization that happened upon the
variable's first unbound reference. (This interpretation appears to have
been further supported by the additional wording in CLtL about not
creating expensive structures that are not needed.)
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all). The cause of the confusion
is the statement that the initial value form is not evaluated unless "it
is used". Better to say that INITIAL-VALUE is evaluated if and only if
the variable does not already have a value. Then there would be no
confusion about the time of evaluation.
Rationale:
This clarification follows the intent of the original Common Lisp
designers.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
None, for most implementations; very small for any the implementation
that adopted delayed evaluation.
Benefits:
This clarification makes the semantics of an important primitive more
well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
The cleanup committee supports this clarification.
∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: DO-SYMBOLS-DUPLICATES (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:17:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:17:05 PDT
Date: 29 May 87 21:16 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 2)
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-211705-1259@Xerox>
Status: I merged in various comments. Ready for release? [use ballot]
Issue: DO-SYMBOLS-DUPLICATES
References: Do-Symbols, Page 187
Category: Clarification
Edit history: Revision 1 by SEF 17-Apr-87
Version 2 by Masinter, add other options
Problem Description:
CLtL specifies that Do-Symbols executes the body once for each symbol
accessible in the package. It does not say whether it is permissible
for the body to be executed more than once for some accessible symbols.
The term "accessible" is defined on page 172 to include symbols
inherited from other packages (not including any symbols that may be
shadowed). It is very expensive in some implementations to eliminate
duplications that occur because the same symbol is inherited from
multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the
body more than once for some symbols.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of
duplicates. For these applications it is unreasonable to force users to
pay the high cost of filtering out the duplications. Users who really
want the duplicates to be removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Adoption Cost:
None. Implemenations would still be free to eliminate the duplications,
though code will not be assuming that this has been done.
Benefits:
Clarification of a situation that is currently ambiguous.
Conversion Cost:
Users who have been assuming that DO-SYMBOLS eliminates duplications
will have to be modified, but such code would run on few existing Common
Lisp systems.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a
clear case of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and
the solution proposed here seems to have been informally agreed to at
the time -- there was no formal decision-making process in place then.
The need for do-symbols to be efficient is questionable, however; for
many applications (e.g., global package manipulation), duplicate values
would create havoc.
For some implementations, the performance penalty would be well over
a factor of two.
Proposal: DO-SYMBOLS-DUPLICATES:ADD-KEYWORDS
Add a keyword argument to the DO-SYMBOLS macro :ALLOW-DUPLICATES (default
value T) which would make the choice explicit. E.g.,
(DO-SYMBOLS (SYMBOL (FIND-PACKAGE "FRED") NIL
:ALLOW-DUPLICATES T
:EXTERNAL-ONLY NIL)
...)
Rationale:
This proposal allows applications which need to be careful the
opportunity to do so.
Current Practice:
No current implementation has this feature.
Adoption Cost:
Implementations which currently can produce duplicates would have
to keep track of symbols which were previously in the macro expansion.
Benefits:
The default case would run efficiently, and yet users could also have
code that guaranteed that there were no duplicates.
Conversion Cost:
Users who have been assuming that DO-SYMBOLS eliminates duplications
would only have to add a :ALLOW-DUPLICATES T.
Aesthetics:
This proposal makes the language slightly more complex, but allows
for both efficiency and accuracy.
Discussion:
Should the default value of :allow-duplicates be nil instead?
∂29-May-87 2118 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:18:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:17:40 PDT
Date: 29 May 87 21:17 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 5)
Message-ID: <870529-211740-1263@Xerox>
Status: Ready for release? [Use ballot]
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history: Revision 2 by cleanup committee 15-Mar-87 15:13:33
Revision 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Revision 4 by SEF 11-Apr-87
Revision 5 by SEF 11-Apr-87
Problem Description:
Do Flet, Labels, Defmacro, Macrolet, Defsetf, Define-Setf-Method, and
Deftype have an implicit block around their bodies like the body of a
Defun? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with Defun.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4
in an implementation that did not add an implicit block around Flet.
Category: Ommission.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by Flet and Labels and each macro created by
Defmacro and Macrolet has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in Defsetf, Define-Setf-Method, and
Deftype is surrounded by a block with the same name as the accessor
or type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
There are two coherent alternatives to the proposal above:
The first would be to keep the implicit block in Defun, and to clearly
state that the other forms do not create implicit blocks. This
violates the goal of consistency between lexical and global definitions,
and it seems to conflict with users' expectations.
The second alternative is to eliminate the implicit block from Defun
rather than adding such blocks to other forms. There is some feeling
that specifying the implicit block in Defun was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
On the other hand, eliminating the implicit block in Defun would be a
significant incompatible change. Some users find this implicit block to
be a great convenience for popping out of convoluted code, and some
existing code makes heavy use of this feature. Such code could be
repaired automatically by searching for situations in which the user
returns from a function by name and by adding an appropriate explicit
block to any function containing such a forms, but it would still
require more more work on existing user code than the proposal made
above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common (perhaps even required) in future
Common Lisp implementations. The outcome of these discussions was
general agreement that a compiler could easily eliminate the implicit
block in any case where it is not actually used, and that the impact on
tail-recursion optimization in compiled code is therefore minimal.
∂29-May-87 2119 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:19:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:18:40 PDT
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-211840-1264@Xerox>
Did I miss this?
----- Begin Forwarded Messages -----
Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 29 APR 87 18:52:14 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127874; Wed
29-Apr-87 21:51:16 EDT
Date: Wed, 29 Apr 87 21:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: FORMAT-OP-C (Version 2)
To: Masinter.pa
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870429-184508-3208@Xerox>
Message-ID: <870429215106.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Sounds right. I'll edit that in to Version 3 with Pavel's
correction when the comments subside.
----- End Forwarded Messages -----
∂29-May-87 2119 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:19:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:19:04 PDT
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 4)
Message-ID: <870529-211904-1265@Xerox>
Status: Ready to release? [Use ballot]
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
Even though there is a predicate FUNCTIONP, it is not synonomous to the
use
of the type FUNCTION; the FUNCTION type cannot be used for
discrimination.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments should be to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions, where a symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this is not a change to the the behavior of Common
Lisp; the descriptions must be changed to accommodate the new definition
of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE is changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression" the behavior of COMPILE should be described as "a
definition from which the implementation is able to reconstruct a
lambda-expression".
Rationale:
This change gives a clean, useful definition to the FUNCTION data type
in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
The definition of FUNCTIONP varies widely between Common Lisp
implementations. No current Common Lisp implementation has exactly the
semantics described here, however.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. Some implementations already always store special
types in function cells, but others, which currently store and return
LAMBDA expressions in SYMBOL-FUNCTION, would be required to change the
behavior of (interpreted FUNCTION).
Some implementations will have to modify the behavior of COMPILE, STEP,
TRACE and (possibly) ED to deal with non-list values in symbol-function
cells.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. One impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
User code which relies on the fact that in some environments,
SYMBOL-FUNCTION returns a list in a well-known format for functions
defined in the lexical global environment will have to change.
Similarly, some implementations currently allow users to say (SETF #'FOO
'BAR) and then subsequently have a redefinition of BAR affect the
behavior of FOO. This would no longer be allowed, and users of those
implementations would have to change their code. Others with home-grown
steppers, trace and advise facilities which manipulated the contents of
function cells might have additional work to do.
User code which uses COMPILED-FUNCTION-P would no longer be valid or
portable.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was written after a discussion of the conversion
problems that such an incompatible change might entail. Some cleanup
committee members would prefer the stronger proposal.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. Fahlman believes that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
Pitman believes that items 4 and 5 are major incopatibilities, and would
prefer if FUNCTION and SYMBOL-FUNCTION be allowed to return things which
are non-functions if those objects can be coerced to functions, and SETF
of SYMBOL-FUNCTION can accept such a coercible object, and the value
later retrieved will be the given object (not a coerced form of it),
though obviously internally some encapsulation may want to go on for
stock hardware to make function calling fast.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
∂29-May-87 2121 Masinter.pa@Xerox.COM Re: Issue GC-MESSAGES (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:21:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:19:58 PDT
Date: 29 May 87 21:19 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue GC-MESSAGES (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 23 Apr 87 23:31 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870529-211958-1267@Xerox>
>Date: Thu, 23 Apr 87 23:31 EDT
>From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>This seems a little short-sighted. GC messages aren't necessarily the
>only unsolicited messages. In the example application you gave, there
>is no reason to treat GC messages differently from other messages.
>Also, a simple on/off switch may be a bit too simple. Not all systems
>have windows, but for the ones that do a three-state switch could be
>defined in an implementation-independent way: (1) turn the messages
off,
>(2) put them in the typescript, (3) make them visible to the user in a
>way that doesn't interfere with the typescript. Even some
>teletype-oriented systems are able to implement option 3.
>In some systems it may not be possible to implement this with a
variable,
>since changing the state of the switch may have to communicate with an
>operating system written in some horrible language. The safest thing
would
>be a macro, whose expansion is system-dependent, and within the dynamic
>extent of the macro's body unsolicited messages are controlled.
>I'm not very optimistic about the possibility of standardizing on this
kind
>of environmental issue, but perhaps some very simple facility to
prevent
>messing up of the screen can be agreed on.
I agree that the GC-MESSAGE issue should be somehow merged with a good
way of dealing with all unsolicited messages.
I can think of other alternatives to the solution proposed by David ("a
macro, whose expansion is system-dependent, and within the dynamic
extent of the macro's body unsolicited messages are controlled.").
I'd like to see the "current practice" section expanded. I know that
Xerox Common Lisp has no unsolicited GC messages, don't know about
Lucid, Gold Hill, Franz, etc.
Kent, since you apparently know what these other systems do ("Other
systems provide ways of enabling or disabling the messages, or
customizing the message which is typed out." perhaps you could
elaborate.)
∂29-May-87 2121 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:21:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:20:25 PDT
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212025-1274@Xerox>
Status: ready for release? [Use ballot]
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: 9-Jan-87, Version 1 by Masinter (from Steele list)
7-Apr-87, merged with other environment argument issues
29-May-87, Version 2 by Masinter, extracted again
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
The language specification should be explicit on the point that
MACROLET, FLET and LABELS can shadow a SETF method; a SETF method
applies only when the global function binding of the name is lexically
visible.
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a users program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee supports this change.
∂29-May-87 2122 Masinter.pa@Xerox.COM IGNORE-ERRORS (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:21:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:20:51 PDT
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
Subject: IGNORE-ERRORS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-212051-1278@Xerox>
Status: Ready for release? [Use ballot]
Issue: IGNORE-ERRORS
References: p428
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87,
Revision 2 by KMP 02/26/87 (fixed typo in sample code),
Revision 3 by KMP 03/11/87 (change to 2nd return value).
Revision 4 by Masinter 29-May-87 minor formatting
Problem Description:
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Proposal (IGNORE-ERRORS:INTERIM):
Remove the apology for the absence of ERRSET (as on p428 of CLtL)
Introduce a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*)
IGNORE-ERRORS executes the given forms in order from left to right,
returning all the values returned by the last form (or NIL if there
are no forms).
If an error occurs while executing the forms, however, no error
message is printed; instead control is silently transfered to the
IGNORE-ERRORS form, which immediately returns a principal value of NIL.
(The return value convention for any other values besides the principal
return value in the case of an error is expressly left undefined in order
to leave room for the full error proposal to attach a useful meaning.)
Rationale:
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.
The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.
Current Practice:
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
Adoption Cost:
We believe this is not difficult to implement in any current implementation.
E.g., IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
`(BLOCK ,TAG
(ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
NIL)))
Benefits:
An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.
Conversion Cost:
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
Aesthetics:
This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
Masinter wonders why KMP isn't spending more time on the error proposal.
The cleanup committee endorses this extension.
∂29-May-87 2123 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:23:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:22:29 PDT
Date: 29 May 87 21:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
To: CL-Cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-212229-1283@Xerox>
Status: I edited this to put some things in different sections
(Aesthetic arguments under aesthetics, cost of converting existing code
into that section) and added some wording to meet Scott's "to prevent
confusion".
Ready for release? [Use ballot]
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument
names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL. That is:
If, following an &key, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY (((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols
arises when the set of non-positional arguments accepted by a function
is
the union of the sets of non-positional arguments accepted by several
other
functions, rather than being enumerated in a single place. In this
case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability
is
the draft proposal for an object-oriented programming standard (CLOS).
It will
have generic functions that accept non-positional arguments and pass
them on
to one or more applicable methods, with each method defining its own set
of
arguments that it is interested in. If this proposal is not adopted,
either
the non-positional argument names will be required to be keywords, which
will require the methods to have non-modular knowledge of each other in
order to avoid name clashes, or the methods will have to be defined with
an
ad hoc mechanism that duplicates the essential functionality of &key but
removes the restriction.
A second example of a Common Lisp application that requires this
capability
is private communication channels between functions. Suppose a public
routine MAKE-FOO needs to accept arbitrary keywords from the caller and
passes those keywords along to an internal routine using keywords of its
own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override
some keyword in keyword-value-pairs, since the only way that could
happen is
if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user
was
programming explicitly in the FOOLAND package, either of which is an
implicit
admission of willingness to violate FOOLAND's modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding
the impact of the proposal.
Change wording which refers to non-positional arguments as being
introduced
by keyword symbols to simply refer to those arguments being introduced
by
symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
Also, the word "keyword" in the first complete sentence on p.62 would
be changed to "symbol" for similar reasons.
Add extra wording on p.60 to explain that by convention keyword
symbols
are normally used as non-positional argument names, and that all
functions
built into the Common Lisp language follow that convention. A
language
manual might or might not choose to describe the circumstances in
which
it is appropriate not to follow this convention.
Add examples to illustrate this behavior. For example, on p.64 the
following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction
that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword
argument name, but allow all non-NIL symbols. (One Symbolics version
that
was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other
things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.
In any case, users who do not want to use the extended functionality
can generally avoid it.
Discussion:
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
Some members of the cleanup committee would just as soon exclude NIL as
a legal keyword-indicator. It might catch some errors, but is possibly
otherwise an odd restriction. Disallowing NIL would reduce the adoption
cost for some implementations.
The cleanup committee supports this change.
∂29-May-87 2124 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:24:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:23:17 PDT
Date: 29 May 87 21:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 2)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212317-1288@Xerox>
Status: Ready to release?
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
CLtL says that a stream can be used as an argument and converted to a
pathname, but pathnames only name files, not other sources or sinks of
data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that
is or was open to a file. For example, it is an error to attempt to
obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: We believe no existing user code relies on any values.
Aesthetics: Makes language a little cleaner.
Discussion: The cleanup committee supports this clarification.
∂29-May-87 2125 Masinter.pa@Xerox.COM Issue: PATHNAME-SYMBOL (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:25:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:23:41 PDT
Date: 29 May 87 21:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212341-1290@Xerox>
Status: Merged comments in. Ready for release? [Use ballot]
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417).
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Category: (Incompatible) CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a
pathname is expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected.
Rationale:
The feature of accepting a symbol was copied by Common Lisp from
Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a
symbol
here was that it did not have strings at all. However, the feature has
been
long since removed from Zetalisp, since it was found to be a source of
bugs
and not to be useful. I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.
One example of the type of bug caused by this occurs when NIL is
erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find
a
table entry that was expected to exist and returned -false-. In systems
that accept symbols as pathnames, this causes a reference to a file
named
"NIL" on some perhaps unexpected directory.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.
Adoption Cost:
It's easy to change implementations to stop accepting symbols. Since
this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.
Benefits:
Pathname functions will be more consistent. In implementations that
check the type of this argument, program error checking will be
improved. In dealing with case-sensitive file systems, users won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not found.
Conversion Cost:
Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings. For example,
some users are used to type interactively (LOAD 'FOO) to mean (LOAD
"FOO").
Aesthetics: Improved by the change.
Discussion:
Some users have reported the "fact" that MERGE-PATHNAMES was in error
because it accepted symbols.
The Cleanup committee supports this change.
∂29-May-87 2127 Masinter.pa@Xerox.COM Status [Part 1]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:27:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:26:19 PDT
Date: 29 May 87 21:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Status [Part 1]
To: cl-cleanup@sail.stanford.edu
Message-ID: <870529-212619-1296@Xerox>
I wanted to get this part out; I haven't updated my status file for the
issues beyond PEEK-CHAR-READ-CHAR-ECHO. I will mail a ballot [Part 1]
separately.
ADJUST-ARRAY-DISPLACEMENT (revision 1)
(Standardize interaction of adjust-array and displacement)
Revision 1 by SEF, 18-Apr-87
Comment by Moon 21 Apr 87
Ready for release?
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
(Extend adjust-array so its OK on non-adjustable arrays, just
makes a new array.)
Not ready for release
Submitted by KMP 22-Apr-87
comments from Moon, JonL, SEF generally against current form
AREF-1D (Version 1)
(Add a new function for accessing arrays with row-major-index)
Submitted 22-Apr-87 by KMP
Some discussion, no strong objection
Ready for release?
ASSOC-RASSOC-IF-KEY
(Extend ASSOC-IF, RASSOC-IF, ASSOC-IF-NOT, etc.
to have a :KEY keyword)
Submitted 22-Apr-87 by KMP
COMPILER-WARNING-BREAK (revision 2)
Not released.
Questions on interaction with condition proposal.
Needs volunteer to pursue.
COMPILER-WARNING-STREAM (Revision 3)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Released.
(Version 4, submittted by SEF was withdrawn --
consider DRIBBLE as a separate issue)
DEFVAR-INITIALIZATION (Revision 3)
((DEFVAR var) doesn't initialize)
Released
remailed 7-apr-87
DEFVAR-INIT-TIME (Version 2)
(DEFVAR initializes when evaluated, not later.)
Submitted 23-Apr-87, Version 1 by Pitman
Version 2 29-May-87 by Masinter
Ready for release?
DO-SYMBOLS-DUPLICATES (Version 2)
(can DO-SYMBOLS see the same symbol twice?)
Version 2 by Masinter
Ready for release?
Question "is it really inefficient to require non-duplicates?"
Add duplicates-allowed keyword?
ENVIRONMENT-ARGUMENTS (revision 1)
SEF summarized issues 18-Apr
Decided to separate again into
GET-SETF-METHOD-ENVIRONMENT,
MACRO-FUNCTION-ENVIRONMENT
SPECIAL-FORM-SHADOW
Not released
FLET-IMPLICIT-BLOCK (Version 5)
(do FLETs have implicit named blocks around them?)
Discussion & agreement on cl-cleanup.
ready for release?
FORMAT-ATSIGN-COLON (Version 3)
Released.
(final form, mailed 17-Apr-87)
FORMAT-NEGATIVE-PARAMETERS
Not written up yet; mail 19-May by KMP
FORMAT-OP-C (Version 2)
(What does ~C do?)
Needs rewording to say "change CL" rather than "change CLtL"
remove mention of ~Q
Not yet released
FUNCTION-TYPE (Version 4)
(Change definition of FUNCTIONP, function type ...)
By Masinter 29-May-87
Ready for release?
GET-SETF-METHOD-ENVIRONMENT (Version 2)
(Environment argument for GET-SETF-METHOD)
By Masinter 29-May-87
Ready for release?
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
Submitted by Pitman 23-Apr-87
In discussion: merge with other controls for
unsolicited messages?
IF-BODY (Version 5)
(extend IF to implicit progn if more than one ELSE form?)
General agreement to recommend against.
Version 5 mailed by KMP , 29-Apr-87
Awaiting a version which KMP and SEF agree
is "fair"
IGNORE-ERRORS (Version 4)
by Masinter 29-May-87
Ready for release?
IMPORT-SETF-SYMBOL-PACKAGE (Version 4)
Version 3 Released
Removed confusing "To further clarify: " sentence
re-release as Version 4
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
by Masinter 29-May-87
Ready for release?
PATHNAME-STREAM (Version 2)
by Masinter 29-May-87
Ready for release?
PATHNAME-SYMBOL (Version 2)
by Masinter 29-May-87
Ready for release?
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
Agreed to be controversial
Withdraw?
∂29-May-87 2128 Masinter.pa@Xerox.COM ***BALLOT *** PART 1 *** BALLOT *** PART 1 ***
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:28:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:27:25 PDT
Date: 29 May 87 21:27 PDT
From: Masinter.pa@Xerox.COM
Subject: ***BALLOT *** PART 1 *** BALLOT *** PART 1 ***
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-212725-1304@Xerox>
Please vote on the following issues which are open. "Release" means to
release the document to X3J13 for discussion & voting.
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[ ] Release as is [ ] Comments follow in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [ ] Release as is [ ] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
∂29-May-87 2133 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 21:33:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:32:30 PDT
Date: 29 May 87 21:32 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 5)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-213230-1315@Xerox>
Status: ready for re-release. (I almost called this Version 3, but with
the addition of the comments of DRIBBLE it really is different.)
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 at committee meeting 15-Mar-87 14:18:56
Revision 3 reformat by Masinter 15-Mar-87 17:42:10
Revision 4 by Fahlman, incorporate Dribble
Revision 5 by Masinter, 29-May-87
revert to version 3 with comment about Dribble.
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.
The cleanup committee supports this change as stated.
∂29-May-87 2214 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 22:14:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:12:59 PDT
Date: 29 May 87 22:12 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-221259-1332@Xerox>
Status: I cannot find any discussion on this topic.
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: GET (SETF), REMPROP, GETF (SETF), REMF, pp. 165-167.
NREVERSE, p. 248.
DELETE, DELETE-IF, DELETE-IF-NOT, DELETE-DUPLICATES,
NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT, pp. 254-256.
NCONC, NRECONC, p. 269.
NBUTLAST, p. 271.
NSUBST, NSUBST-IF, NSUBST-IF-NOT, p. 274.
NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR, p. 276-279.
Edit history: Version 1 by DLA@SCRC-STONY-BROOK.SCRC.Symbolics.COM
Problem Description:
Currently, the exact nature of the list modification
performed by REMF and REMPROP is not specified. Conversation on the
Common-Lisp mailing list has made it clear that this situation is not
good. The list modification allowed should either be specified, or
explicitly documented as unspecified and up to the individual
implementation. If the list modification is specified, then programmers
can rely on the specification. If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.
This argument can be made for most of the destructive functions
specified above, and possibly others, so they are included as
references.
Category: clarification
Proposal: REMF-DESTRUCTION-UNSPECIFIED:DONT-SPECIFY
I propose that CLtL's documentation on each of the above functions
include a statement such as the following: "This function performs a
modification to the top-level [list] structure of its argument(s).
Different implementations may choose different modifications of the list
structure, as long as the function otherwise fulfills its contract. It
is an error to rely on the list destruction being performed in any
particular way. Any references to the list structure of the argument(s)
other than the value(s) returned are therefore undefined after the function
returns."
Rationale:
Benefits:
Implementations can improve performance of
many of the referenced functions when they are not under the constraint
to implement them in a specified fashion or "in the most logical
fashion". For example, on the Symbolics 3600, DELETE of a cdr-coded
list could use the implementation primitive %CHANGE-LIST-TO-CONS rather
than RPLACD to avoid creating forwarding pointers. As another example,
all of the destructive operations which remove objects could remove CAR
pointers to removed objects which are more volatile than the list
itself, assisting the garbage collector.
Most of the referenced functions implement abstract operations, for
example REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Aesthetics:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are currently in such danger, and this change to the documentation would
just publicize it. The clarification would ENCOURAGE good programming
practice by warning people to only obey the published contract of the
referenced functions.
Current practice:
Symbolics Common Lisp already implements some of the functions in a
non-obvious fashion. For example, in Symbolics Common Lisp:
(setq foo (list 'a 'b 'c)) ==> (a b c)
(setq bar (cdr foo)) ==> (b c)
(setq foo (delete 'b foo)) ==> (a c)
bar ==> ((c)) ; most people would guess (b c).
(eq (cdr foo) (car bar)) ==> t
Cost of adopting change:
There is no cost of adopting this change to developers.
------------------------------------------------------------
Alternative proposal: REMF-DESTRUCTION-UNSPECIFIED:DO-SPECIFY
Some or all of the functions could be documented to
perform the list destruction in a specified manner.
Rationale and Advantages: (1) The "additional features" may be more
useful to some programmers. (2) Programmers may expect the functions to
do the "expected" destructive operation. (3) Compatibility with other
dialects. For example, it may be easier to port a Zetalisp program to
Common-Lisp if REMPROP returns a sublist pointer as defined in Zetalisp.
If this alternative is pursued, then many implementations may be forced
to incompatibly change what their functions do. This may break existing
programs and may cause the implementation to have poorer performance.
∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: TAILP-NIL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:09:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:36:59 PDT
Date: 29 May 87 22:36 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: TAILP-NIL
to: CL-cleanup@Sail.stanford.edu
Message-ID: <870529-223659-1341@Xerox>
I've been putting this issue in the status list, but had never mailed it
out. It is not yet in proper format.
For the record:
Issue: TAILP-NIL
Reference: Steele p.275
Category: clarification
Description:
The description of tailp in Steele differs from current implementations
in the case where the first argument is NIL. In particular, the second
sentence "Another way to look at this is tailp is true if (nthcdr n
list) is sublist, for some value of n." does not accurately describe
current practice for the case where sublist is nil.
The behavior of TAILP on circular structures is also unspecified, e.g.,
is (tailp '() '#0=(x . #0#)) meaningful?
Proposal: TAILP-NIL:RETURN-NIL
Clarify that (TAILP NIL X) returns NIL for all lists X, and that tailp
must be true-false-indeterminate equivalent to
(defun tailp (x y)
(and x y (or (eq x y) (tailp x (cdr y)))))
i.e., if the second argument is circular and the first argument is not a
"tail" of the non-circular part of it, tailp may loop indefinitely.
∂29-May-87 2310 Masinter.pa@Xerox.COM Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:10:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:45:46 PDT
Date: 29 May 87 22:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
In-reply-to: Masinter.pa's message of 29 May 87 22:12 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-224546-1347@Xerox>
I had written too many destructuring-bind's recently, and mistyped the
issue name as REMF-DESTRUCTURING-UNSPECIFIED. Sorry.
∂29-May-87 2310 Masinter.pa@Xerox.COM Status, Part 2
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:10:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:42:28 PDT
Date: 29 May 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Status, Part 2
To: cl-cleanup@sail.stanford.edu
Message-ID: <870529-224228-1344@Xerox>
This is part 2 of the status file. Please mail any corrections you have.
(I was closer to being done than I thought!)
PRINC-CHARACTER (Version 3)
Mailed by KMP 29-Apr-87.
Ready for release?
PROCLAIM-LEXICAL (Version 1)
In discussion
Reaching convergence
Need volunteer to merge comments into new version
PROMPT-FOR (Version 1)
Agreed to be controversial
Withdraw?
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Not yet submitted.
REMF-DESTURCTION-UNSPECIFIED (Version 1)
Submitted by DLA
Discussion?
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Version 2 by KMP 28 Apr 87
In discussion, no clear consensus
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Mild for this proposal, but preference for
removing FONT and BITS attribute
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Withdraw?
SHARPSIGN-PLUS-MINUS-PACKAGE
Seems like general agreement for :KEYWORD.
Need to remove other options from proposal.
TAILP-NIL
Not yet submitted.
Needs volunteer to format.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
In discussion
Need volunteer to summarize issues.
∂29-May-87 2310 Masinter.pa@Xerox.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87 23:10:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:42:47 PDT
Date: 29 May 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-224247-1345@Xerox>
I found that I had fewer ballot items for the remaining issues on the
list -- just to liven it up, I stuck in a couple of ringers.
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
PROMPT-FOR (revision 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else [
] Undecided
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
∂30-May-87 0715 MATHIS@ADA20.ISI.EDU Re: barrage of mail coming
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 May 87 07:15:38 PDT
Date: 30 May 1987 07:15-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: barrage of mail coming
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]30-May-87 07:15:01.MATHIS>
In-Reply-To: <870529-211317-1248@Xerox>
Larry,
How are we going to send this to the general membership of X3J13?
I can send you updated mailing labels. I also think that
electronic mail would be good.
I was thinking about the following style agenda for Boston:
Tuesday Morning -- clean-up committee
Tuesday afternoon -- Japanese characters presentation, X windows
presentation, administrative work of committee
Wednesday Morning -- clean-up committee
Wednesday afternoon -- remaining stuff
How does that sound to you?
Also, is it useful to have a meeting of this committee on Monday.
We picked Tuesday and Wednesday for the main meeting so we could
use Monday for subcommittees if needed.
Bob
∂31-May-87 2051 masinter.pa@Xerox.COM ballots, meeting, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 May 87 20:50:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 31 MAY 87 20:50:05 PDT
From: masinter.pa@Xerox.COM
Date: 31 May 87 20:49:38 PDT
Subject: ballots, meeting, etc.
To: cl-cleanup@sail.stanford.edu
Message-ID: <870531-205005-2070@Xerox>
I'd like to ask you, if you think you might have some opinions on some
or all of the issues, but don't have the time to respond now, to please
reply to that effect. I don't want to mail out proposals unless there is
consensus that they are ready for release.
MEETING:
I would like to get together Monday for a subcommittee meeting. I'd like
to discuss some of the more serious open issues and see how much
progress we can make. (PROCLAIM-LEXICAL seems like it might benefit from
a face-to-face discussion.)
What do you think about taking some time to go over the ISSUES.TXT file
and getting some directions on them for us to proceed?
Other agenda items?
I expect to be flying in on Sunday, and so would be available all day
Monday. We probably will need to dig up a meeting room somewhere, too.
∂01-Jun-87 1217 JAR@AI.AI.MIT.EDU Status, Part 2
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 12:17:39 PDT
Date: Mon, 1 Jun 87 15:19:35 EDT
From: "Jonathan A. Rees" <JAR@AI.AI.MIT.EDU>
Subject: Status, Part 2
To: Masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of 29 May 87 22:42 PDT from Masinter.pa at Xerox.COM
Message-ID: <208084.870601.JAR@AI.AI.MIT.EDU>
Date: 29 May 87 22:42 PDT
From: Masinter.pa at Xerox.COM
PROCLAIM-LEXICAL (Version 1)
In discussion
Reaching convergence
Need volunteer to merge comments into new version
I think that "reaching convergence" is a little too optimistic.
∂01-Jun-87 1449 edsel!kent-state!eb@navajo.stanford.edu AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 14:49:34 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:00 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA09873; Mon, 1 Jun 87 14:11:32 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA07192; Mon, 1 Jun 87 14:11:22 PDT
Date: Mon, 1 Jun 87 14:11:22 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012111.AA07192@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
Subject: AREF-1D
I agree with Version 1, with one exception. I prefer the name
ROW-MAJOR-AREF to AREF-1D. With this change I support releasing this
proposal.
∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 14:50:09 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:14 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA09918; Mon, 1 Jun 87 14:27:22 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA07224; Mon, 1 Jun 87 14:27:11 PDT
Date: Mon, 1 Jun 87 14:27:11 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012127.AA07224@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
Subject: PATHNAME-SYMBOL
If a symbol can be coerced into a string, and a string can be coerced
into a pathname, I see no reason why a symbol should not be coerced
into a pathname. It has limited usefulness, but I believe that
coercions should be transitive. I believe that the aesthetics of the
language will be harmed by disallowing symbols as pathnames.
I'm not going to put up a fight to stop this change, but I would like
to see the minority view stated in the proposal.
∂01-Jun-87 1450 edsel!kent-state!eb@navajo.stanford.edu ***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 14:50:41 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:45 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA09961; Mon, 1 Jun 87 14:39:45 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA07238; Mon, 1 Jun 87 14:39:33 PDT
Date: Mon, 1 Jun 87 14:39:33 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012139.AA07238@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 29 May 87 21:27 PDT <870529-212725-1304@Xerox>
Subject: ***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[x] Release as is [ ] Comments follow in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [x] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [ ] Release as is [x] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [x] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [x] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
PROMPT-FOR (revision 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [x] UNCHANGED [ ] Something else [
] Undecided
SHARPSIGN-BACKSLASH-BITS
BALLOT: [x] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
∂01-Jun-87 1650 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 16:50:45 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 16:47:09 PDT
Date: 1 Jun 87 16:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Masinter.pa's message of 29 May 87 21:18 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870601-164709-3170@Xerox>
I don't like the current, 'concession to backward compatibility' which
allows apply, mapcar etc. to accept things which are not functionp. I
bet the amount of code which would be affected by this change is small,
and if we decide to make it now, vendors can make their systems warn
about it for a while, so the transition should not be too painful.
Face it, more code is going to be written than has already been written,
lets look to the future, not the past.
Now if only this argument could sway the Lisp-1 issue...
∂01-Jun-87 1715 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 17:14:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161104; Mon 1-Jun-87 20:14:13 EDT
Date: Mon, 1 Jun 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870601-164709-3170@Xerox>
Message-ID: <870601201413.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 1 Jun 87 16:46 PDT
From: Gregor.pa@Xerox.COM
I don't like the current, 'concession to backward compatibility' which
allows apply, mapcar etc. to accept things which are not functionp. I
bet the amount of code which would be affected by this change is small,
and if we decide to make it now, vendors can make their systems warn
about it for a while, so the transition should not be too painful.
This kind of warning strategy isn't very effective for things that cannot
be detected at compile time. A run time warning tends to be a big annoyance
and may not tell you just where in your program was responsible for the
effect.
∂01-Jun-87 1810 Pavel.pa@Xerox.COM AREF-1D
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 18:09:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:07:53 PDT
Date: 1 Jun 87 18:07 PDT
From: Pavel.pa@Xerox.COM
Subject: AREF-1D
To: cl-cleanup@sail.stanford.edu
Message-ID: <870601-180753-3283@Xerox>
I favor this proposal in principal, but would much rather use the more
mnemonic name ROW-MAJOR-AREF instead of AREF-1D.
Pavel
∂01-Jun-87 1822 Pavel.pa@Xerox.COM DO-SYMBOLS-DUPLICATES
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 18:22:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:21:57 PDT
Date: 1 Jun 87 18:21 PDT
From: Pavel.pa@Xerox.COM
Subject: DO-SYMBOLS-DUPLICATES
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <870601-182157-3303@Xerox>
I think that I favor something like the DO-SYMBOLS:ADD-KEYWORD proposal,
but I'm not willing to vote for it as it. The problem is that the
example in the proposal contains a keyword not described by the
proposal, namely :EXTERNAL-ONLY. Also, the proposal does not specify
which, if any, of the arguments following the return-value expression
are to be evaluated. In short, it is not a complete proposal.
I like the idea of having a single package-iteration macro, flushing
ones like DO-EXTERNAL-SYMBOLS. Probably the best way to do this is to
have some set of orthogonal attributes selectable by keyword. It would
be nice if the same keywords were the arguments to some functional
interface to package-iteration, such as the MAPATOMS function in
Interlisp. Then the flavor of the iterative macro would be more like
WITH-OPEN-FILE, whose options are just those available from OPEN.
In any case, I think that allowing the duplicates is probably the wrong
thing in general, so I can't vote in favor of either of the two
proposals.
Pavel
∂01-Jun-87 1830 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 18:29:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:29:18 PDT
Date: 1 Jun 87 18:29 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Masinter.pa's message of 29 May 87 21:18 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870601-182918-3312@Xerox>
Typo in the proposal:
``it is not synonomous to the use of the type FUNCTION'' should be ``it
is not synonomous with the use of the type FUNCTION''.
∂01-Jun-87 2041 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: TAILP-NIL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:41:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161243; Mon 1-Jun-87 23:36:32 EDT
Date: Mon, 1 Jun 87 23:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL
To: CL-cleanup@Sail.stanford.edu
In-Reply-To: <870529-223659-1341@Xerox>
Message-ID: <870601233632.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I vote against releasing this issue until its writeup is in proper format.
When you write the current practice section, mention that Symbolics
follows the second of the two contradictory sentences in the tailp
writeup, hence (tailp nil <anything>) => t. This may mean that current
practice is not uniform.
For history, you can mention that the unambiguous definition in the
MIT Lisp Machine Manual (I consulted the fourth edition) would require
(tailp nil <anything>) => nil.
I personally don't care which disambiguation is adopted. If the writeup
includes a proposal to eliminate the function, I will vote for that, since
I've never understood what use tailp is.
∂01-Jun-87 2047 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:47:29 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161244; Mon 1-Jun-87 23:44:37 EDT
Date: Mon, 1 Jun 87 23:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-212051-1278@Xerox>
Message-ID: <870601234627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
...
Issue: IGNORE-ERRORS
...
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
Masinter wonders why KMP isn't spending more time on the error proposal.
...
I'd like to encourage you to remove this somewhat random comment, which may
be viewed by outsiders as being more critical than you hopefully meant. In
fact, KMP is spending a -lot- of time on the error proposal.
The problem is that KMP has what he thinks is a clear understanding
both of the length of time it takes to get things of that size through
a political mechanism such as X3J13 even under ordinary circumstances,
and is -very- leary about potential last-minute snags due to the
emergence of CLOS in parallel and the fact that people will likely
want last-minute "small changes" to make it take more advantage of CLOS.
The presence of this item as a place-holder while all the business of
acceptance is in progress is particularly important to me. The more vendors
who provide this as a private extension in the very near term, the fewer
utterly random interfaces they'll conjure instead. Like it or not, existing
code has to interface to the private extensions until this standard is marked
approved, but we can do a lot to improve quality of life by at least hinting
that this is coming. In Macsyma, there's a definition of IGNORE-ERRORS that
does:
#+LispM `(CONDITION-CASE (-ERROR-)
(VALUES (PROGN ,@FORMS) NIL)
(ZL:SYS:ERROR (VALUES NIL -ERROR-)))
#+(OR ...other-systems...)
`(LET ((RESULT (ERRSET (PROGN ,@FORMS) NIL)))
(IF RESULT
(VALUES (CAR RESULT) NIL)
(VALUES NIL T)))
#+(OR ...more-other-systems...)
...etc.
Each new case added requires careful study of the host error system to
figure out how to attach an IGNORE-ERRORS. If everyone had the idea that
at least IGNORE-ERRORS was worth latching onto, I think they'd at least
do that even if they weren't sure of the rest of the emerging error system,
and I think the resulting convergence would be very useful.
∂01-Jun-87 2050 Moon@STONY-BROOK.SCRC.Symbolics.COM PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:50:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161246; Mon 1-Jun-87 23:45:22 EDT
Date: Mon, 1 Jun 87 23:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PATHNAME-SYMBOL
To: Eric Benson <edsel!kent-state!eb@navajo.stanford.edu>, Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8706012127.AA07224@kent-state.edsel.uucp>
Message-ID: <870601234525.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 1 Jun 87 14:27:11 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
If a symbol can be coerced into a string, and a string can be coerced
into a pathname, I see no reason why a symbol should not be coerced
into a pathname. It has limited usefulness, but I believe that
coercions should be transitive. I believe that the aesthetics of the
language will be harmed by disallowing symbols as pathnames.
I'm not going to put up a fight to stop this change, but I would like
to see the minority view stated in the proposal.
Stating minority views in proposals is a good idea, but don't forget the
following point KMP made a couple of weeks ago. I only mention this
because the point about alphabetic case doesn't appear explicitly in the
version 2 writeup. I'd say the succinct form of this point is that
strings preserve the case that you type in, but symbols don't, they
force to uppercase. This doesn't affect me, since I don't enjoy a file
system with case-sensitive file names, but it affects a lot of people.
* Note that the biggest impact of this change on users is that
they will not be able to say (LOAD'FOO) which they commonly type
interactively to mean (LOAD "FOO"). One advantage, of course, is
that in case-sensitive file systems, people won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not
found. Still, I think the fact that we're going to make it an
error for people to type (LOAD 'FOO) is worth documenting as part
of the cost of this proposal so that no one ends up surprised.
One note I had about KMP's remark:
Nothing in CLtL says that a symbol is allowed as an argument to LOAD,
unless we take all occurrences of the string "filename" in italics
to be typos for "pathname" in italics. See pp.413,418,426.
∂01-Jun-87 2055 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 20:55:06 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161252; Mon 1-Jun-87 23:53:19 EDT
Date: Mon, 1 Jun 87 23:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: People's names
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I changed my name from KMP to Pitman in a bunch of proposals
because I thought it would be better for the X3J13 people who
aren't regular readers of net mail and might not put the two
together.
I notice in your summaries that sometimes I come out as KMP
and other times as Pitman. I'd appreciate if you could either
change the ones I missed to say Pitman or publish an index
that says what a KMP is (in which case I'd like to be KMP
everywhere).
Presumably, the same reasoning should apply for SEF, etc.
In fact, SEF doesn't even use the name SEF as his login name,
so that may be even more confusing to some.
Once we adopt a convention, we can just use it regularly and then
there need be no further last-minute touch-ups of this sort.
∂01-Jun-87 2121 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue 2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-211904-1265@Xerox>
Message-ID: <870602001135.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
Even though there is a predicate FUNCTIONP, it is not synonomous to the
use of the type FUNCTION; the FUNCTION type cannot be used for
discrimination.
I don't think that's true. I believe CLtL p.47 is meant to say that a
list type-specifier with FUNCTION in the car cannot be used for
discrimination, while Table 4-1 combined with CLtL p.72 indicates that
the symbol type-specifier FUNCTION can be used with TYPEP. I would
simply remove this paragraph from the proposal. Later in the proposal
you have an explicit statement that the symbol type-specifier FUNCTION
can be used for discrimination.
This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
If it also removes the COMPILED-FUNCTION type-specifier, say so here.
∂01-Jun-87 2122 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:22:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161269; Tue 2-Jun-87 00:12:38 EDT
Date: Tue, 2 Jun 87 00:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870601-180753-3283@Xerox>
Message-ID: <870602001244.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 1 Jun 87 18:07 PDT
From: Pavel.pa@Xerox.COM
I favor this proposal in principal, but would much rather use the more
mnemonic name ROW-MAJOR-AREF instead of AREF-1D.
I agree.
∂01-Jun-87 2121 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:21:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161264; Tue 2-Jun-87 00:09:32 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870529-212341-1290@Xerox>
Message-ID: <870602001130.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The grinding of the PATHNAME-SYMBOL proposal needs to be cleaned up.
It came through looking like this to me:
...
Rationale:
The feature of accepting a symbol was copied by Common Lisp from
Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a
symbol
here was that it did not have strings at all. However, the feature has
been
long since removed from Zetalisp, since it was found to be a source of
bugs
...
Also, I find the treatment of LOAD is not uniformly carried through.
For example, the proposal mentions LOAD at one point under conversion
cost. It may want to mention it under aesthetics, too. But in any case,
it should surely state definitively that LOAD is affected in the Proposal
and the References.
By the way, in the Symbolics release I'm using (7.1) allows (LOAD 'symbol)
so the comment saying we've long since flushed the feature is not completely
accurate. It may be that Moon didn't mean to include LOAD, in which case
the discussion should be phrased to make it clear that LOAD is not intended.
I think this will be a likely source of grumbling at X3J13; we might as
well head it off early. I won't vote to release this until the wording is
made to treat LOAD clearly.
∂01-Jun-87 2126 Moon@STONY-BROOK.SCRC.Symbolics.COM ***BALLOT ***
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:26:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161284; Tue 2-Jun-87 00:25:41 EDT
Date: Tue, 2 Jun 87 00:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ***BALLOT ***
To: cl-cleanup@Sail.stanford.edu
In-Reply-To: The message of 30 May 87 00:27 EDT from Masinter.pa@Xerox.COM,
<870529-212725-1304@Xerox>,
The message of 30 May 87 01:42 EDT from Masinter.pa@Xerox.COM,
<870529-224247-1345@Xerox>
Message-ID: <870602002546.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here are my votes on both part 1 and part 2 of the ballot:
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[x] Release as is [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
;Okay for release if name is changed to ROW-MAJOR-AREF
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [x] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup
;I don't have comments to offer on this, but it does seem
;that there is some justification for not releasing it,
;instead replacing it with a more complex proposal involving
;lots of keyword options. However I can't support
;DO-SYMBOLS:ADD-KEYWORD in its present incomplete form.
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
;Okay for release if the two comments I sent in mail are addressed
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [ ] Release as is [x] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [x] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PROMPT-FOR (revision 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
I cannot vote on the following, as I have not received copies of them.
Or if I have, it was so long ago that I have lost them, and even if
I hadn't lost them, I wouldn't trust them to be up to date.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
;If those are the only two choices, "withdraw" always wins!
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
;I support strict left to right evaluation order, which I believe
;to be the current definition of Common Lisp. I can't figure
;out which checkbox means left-to-right.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else [
] Undecided
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
∂01-Jun-87 2137 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:36:36 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161299; Tue 2-Jun-87 00:35:40 EDT
Date: Tue, 2 Jun 87 00:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 3)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870602003737.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Changes since version 2:
* Pavel's request to strike reference to ~Q at the end of the
Problem Description field.
* Masinter's request to reword proposal to not talk directly about
modifying CLtL in the Proposal field.
* The last paragraph of the Discussion field is new.
-kmp
-----Proposal Follows-----
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (merge Moon's suggestion)
29-Apr-87, Version 3 by Pitman (misc editing)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should
be culturally compatible with the host environment." This description
is not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose
that wasn't planned on:
(FORMAT NIL "~C" #\Space) might "Space" rather than " ".
[Anyone who would argue that the word `abbreviated' in the definition
was supposed to prevent this should just be happy that some implementors
didn't choose to interpret that word to mean that "Sp" should come back.]
Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and
~:C equivalently or very similarly, which seems like a waste of a FORMAT op.
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; FORMAT does not suffice.
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. Leave the behavior
of ~C with non-zero bits incompletely specified. For example, the
description of ~C on p389 of CLTL might read:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Clarify that WRITE-CHAR puts only one character on its argument stream,
but which allows that stream to perform arbitrary destination-dependent
actions based upon that character:
Note: The glyphs used to present characters which are not in
the standard character set may vary from implementation to
implementation or output device to output device. WRITE-CHAR
will always output a single character to the indicated stream.
On some streams, super-quoting, character substitution, or
substitution of a string for a single character may be
necessary; it is appropriate for the stream to decide to do
this, but WRITE-CHAR itself will never do this.
Rationale:
This was probably the intent of the authors.
It makes things clear enough that programmers can know what to
expect in the normal case (standard characters with zero bits)
while leaving some flexibility to implementors about what to do in
the case of bits (which are not particularly well-defined across
different implementations anyway).
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would suffer an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable.
As things stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of
"~C" and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as
a simplification.
Discussion:
KMP and Pavel support this proposal.
KMP thinks it's important to get this cleared up as soon as possible.
Moon's comment on Version 1 (which tried to make WRITE-CHAR and ~C
identical in all cases) was:
I believe the error in CLtL is that it was not stated explicitly
that the "implementation-dependent abbreviated format" applies only
to characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as write-char for characters
with zero char-bits. I don't think we want to require ~C and
write-char to do the same thing for characters with bits.
Steele and Fahlman seemed to like the idea of the proposal if amended
as Moon suggested. Pitman did the merge, creating Version 2. If he didn't
blow it somehow, they should now be happy.
Moon and Fahlman voiced support for version 2.
Fahlman thinks the problem description is too long.
KMP isn't sure if he agrees that the problem description is too long,
but doesn't think it's worth anyone's time to edit it.
∂01-Jun-87 2151 Moon@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:50:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161302; Tue 2-Jun-87 00:41:11 EDT
Date: Tue, 2 Jun 87 00:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870601234627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602004111.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
From: Kent M Pitman <KMP@STONY-BROOK>
The presence of this item as a place-holder while all the business of
acceptance is in progress is particularly important to me.
In light of this, I'd like to modify my vote to say that I don't care
whether IGNORE-ERRORS is released in its present form (minus gratuitous
personal comments about how KMP spends his time) or withdrawn in
deference to the error proposal.
∂01-Jun-87 2152 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 21:52:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161307; Tue 2-Jun-87 00:51:50 EDT
Date: Tue, 2 Jun 87 00:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870602001130.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602005157.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 2 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
The grinding of the PATHNAME-SYMBOL proposal needs to be cleaned up.
This happens to most mail that passes through Xerox. I don't think they
see it in their own mail reader, but in the outside world it gets
reformatted as alternating long and short lines if the lines are longer
than a small maximum.
By the way, in the Symbolics release I'm using (7.1) allows (LOAD 'symbol)
so the comment saying we've long since flushed the feature is not completely
accurate.
Try ZL:LOAD if you want to see what it does in Zetalisp. But CL:LOAD doesn't
allow symbols in 7.1 for me, so maybe you've "fixed" it in your init file?
I don't think I've "fixed" it in mine.
It may be that Moon didn't mean to include LOAD, in which case
the discussion should be phrased to make it clear that LOAD is not intended.
CLtL already does not say that LOAD accepts symbols as arguments, unless we
are to think that when it says "filename" it means "pathname", and when it
discusses what arguments named "pathname" mean 13 pages earlier, it means to
include LOAD.
I certainly didn't mean to propose to change the language to make LOAD allow
symbols.
Does this mean that we need to withdraw PATHNAME-SYMBOL in favor of a more
comprehensive proposal to fix all the ambiguities and incomplete specifications
in chapter 23? That would be nice, but it's a big job. Maybe we could just
cover every argument that is called pathname, filename, file, or new-name
and leave the rest of the ambiguities for another proposal?
∂01-Jun-87 2209 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 22:09:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161319; Tue 2-Jun-87 01:08:02 EDT
Date: Tue, 2 Jun 87 01:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: Masinter.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <870529-211354-1250@Xerox>
Message-ID: <870602010958.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
Issue: ADJUST-ARRAY-DISPLACEMENT
I'm happy with most of this clarification as far as it goes, but I have a
few other things that I'd like to see cleaned up before it goes out...
...
(4) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element. However, the use of
:initial-contents causes all old contents to be discarded.
Hmm. I can almost get COPY-ARRAY out of this, couldn't I? Maybe...
(DEFUN COPY-ARRAY (ARRAY)
(ADJUST-ARRAY (MAKE-ARRAY (ARRAY-DIMENSIONS ARRAY)
:ELEMENT-TYPE (ARRAY-ELEMENT-TYPE ARRAY)
:DISPLACED-TO ARRAY)
:DISPLACED-TO NIL))
This isn't one of the things I necessarily think needs clarification. I just
thought it was curious. The rest of this message is of more significant interest.
Note that if array X is displaced to array Y, and array Y is displaced
to array Z, and array Y is altered by Adjust-Array, array X must now
refer to the adjusted contents of Y. ...
I'm happy with this statement, but it sounds like it follows from one or
more of the four previous rules, and I'm not clear which. If it really
redundant, perhaps you could make the reason more clear. If not, it
shouldn't begin with "Note that...".
As nearly as I can tell, the discussion of ADJUST-ARRAY both here and in
CLtL does not say what happens if :DISPLACED-TO is omitted. Ie, is
(ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A))
the same as
(ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A) :DISPLACED-TO NIL)
or the same as
(ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A) :DISPLACED-TO A)
?
The current style of wording looks like the sort of clever :ADJUSTABLE
wording that got us into such a frenzy. Even if there's intentional ambiguity,
we should be clear about that fact. My guess, though, is that no ambiguity
was intended here.
∂01-Jun-87 2221 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 22:20:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161330; Tue 2-Jun-87 01:20:11 EDT
Date: Tue, 2 Jun 87 01:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602012209.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I changed the name of the function from AREF-1D to ROW-MAJOR-AREF,
re-filled some of the text to fit better in 80-columns, and marked
KMP, GLS, Moon, JonL, Benson, and Pavel as supporting this amended
version in the Discussion field. Other than that, no changes.
-----Proposal Follows-----
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman,
02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
Status: For Internal Discussion
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying
arity. Currently, you have to make a displaced array to work with
temporarily and then throw away the displaced array when you're done.
In the case of FILLARRAY, I find this bothersome because there is no
a priori reason why FILLARRAY should have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF which allows 1D access to the
storage backing up a given array assuming the normal row-major storage
layout.
This accessor should be valid for use with SETF.
Rationale:
We already document the row-major storage layout and have a number of
operators which allow users to exploit that order. This would be a
useful addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops which had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this involves
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name
for use internally. In Symbolics systems, for example, it is
SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations which already
use this primitive internally, it's little more than a matter of
changing the name of or otherwise releasing the existing primitive.
In some implementations, it might involve writing a small amount of
code (and associated compiler optimizers).
Benefits:
This gives users efficient access to something which they already have
inefficient access to.
Conversion Cost:
This is an upward-compatible change.
Aesthetics:
I think this allows certain programs to be written in a more aesthetic way.
Discussion:
KMP and GLS support this proposal.
Moon, JonL, Benson, and Pavel expressed conditional support of version 1,
asking that the name be changed from AREF-1D to ROW-MAJOR-AREF. KMP and
GLS did not oppose this change, so it was made for version 2.
∂02-Jun-87 0041 masinter.pa@Xerox.COM schedule
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Jun 87 00:41:40 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 02 JUN 87 00:41:13 PDT
From: masinter.pa@Xerox.COM
Date: 2 Jun 87 0:40:46 PDT
Subject: schedule
To: cl-cleanup@sail.stanford.edu
Message-ID: <870602-004113-3549@Xerox>
I've gotten several ballots, but by no means all.
I'll be out tomorrow and fairly busy on Wednesday, so I thought I could
summarize the ballots on Thursday, mail out revised versions of any of
the proposals that had only typographical corrections to this group and
a revised status.
My target for mailing to X3J13 is next week. (Bob Mathis, if you are
listening, please send mailing labels!!!)
∂02-Jun-87 0226 KMP@STONY-BROOK.SCRC.Symbolics.COM *** BALLOT ***
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Jun 87 02:26:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161499; Tue 2-Jun-87 05:25:43 EDT
Date: Tue, 2 Jun 87 05:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *** BALLOT ***
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-212725-1304@Xerox>,
<870529-224247-1345@Xerox>
Message-ID: <870602052736.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
ADJUST-ARRAY-DISPLACEMENT (revision 1)
BALLOT: [ ] Release as is [x] Comments precede in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments precede in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
AREF-1D (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
[x] Release version 2
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD
[x] Other: comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
Note: I'd really be happiest if this was broken in two, so I could
support the half I like and only grump about the parts I don't
like. If we're going to deal with it all as one bundle, I feel
obliged to hold up the whole thing for a bit because I believe
there is useful progress still to be made amongst ourselves
prior to releasing this to the masses.
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
Note: I would like to see NIL be allowed to designate the null lexical
environment, but I won't hold up the proposal for this if anyone
disagrees.
IF-BODY (Version 5)
BALLOT: [x] Release as is
[ ] Wait for version that SEF and KMP agree is "fair".
Note: I'm not trying to be pushy; I just assume I must vote Yes to
avoid a gentleman's deadlock. If SEF disagrees and wants to do
further editing, I'm willing to have this put on hold for another
round. I don't plan to let this fall victim to a pocket veto,
however.
IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [ ] Wait for error proposal
[ ] Comments follow in mail to cl-cleanup
[x] Release with minor changes to discussion as mentioned in
recent mail.
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
Note: The copy of this which I received recently has been filled
oddly and needs to be reformated if it looked that way before
it went through someone's (Larry's?) mailer.
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal.
[ ] Comments follow in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
Note: This term "withdraw" really bugs me. These item names are the names
of issues, not proposals. The proposal names have ":something"
appended. Seems to me that issues oughtn't get withdrawn, they
should just be placed on hold.
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first)
[ ] unspecified [ ] Proposal follows in mail to cl-cleanup
Note: I'm not sure if this ballot item is for real. Clearly the topic
warrants serious discussion, but I have no opinion right now so am
not going to risk it.
PROMPT-FOR (revision 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED
[ ] Something else [x] Undecided
Note: I am not clear on whether I support GENERALIZE or MODIFIED. I want to
spend more time looking at this when I get a chance. I don't think we
should propose anything firm yet.
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal
[ ] Want proposal for removing BITS and FONT from standard
[ ] Want fuller character proposal
[ ] Comments follows in mail to cl-cleanup
[x] Place on hold pending resolution of comments already received.
∂02-Jun-87 1016 RPG Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
Moon writes about Gregor's suggestion to warn on bad arguments to APPLY:
``This kind of warning strategy isn't very effective for things that cannot
be detected at compile time. A run time warning tends to be a big annoyance
and may not tell you just where in your program was responsible for the
effect.''
This might be right, but I'd rather there be an annoyance during a
period when old code is fixed than have years of bad news simply because
of a sentimental attachment to MacLisp. Here's my proposal: Let the vendors
make the change and let the users fix their code.
-rpg-
∂02-Jun-87 1148 Gregor.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Jun 87 11:48:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JUN 87 11:32:42 PDT
Date: 2 Jun 87 11:32 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 1 Jun 87 20:14 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870602-113242-4179@Xerox>
Date: Mon, 1 Jun 87 20:14 EDT
From: David A. Moon
This kind of warning strategy isn't very effective for things
that cannot be detected at compile time. A run time warning tends
to be a big annoyance and may not tell you just where in your
program was responsible for the effect.
True, but I think many of the cases could in fact be detected at run
time. Of course I have not done an extensive search, and there may well
be large bodies of code for which this is not true. Those large bodies
of code will require hand analysis and conversion.
Here is another point which I think is relevant to this discussion.
Define the Z of a lisp programmer to be their familiarity with the
subleties of Lisp programming. This includes things like the history of
Lisp, what dynamically scoped Lisps are like, what Lisp-1s are like etc.
etc. It seems to me that as time goes on, the average Z of lisp
programmers is going to go down. In some sense, that is what it means
for Lisp to become a successful language. An effect of this, is that in
most cases, it is going to be much easier for the people who have
written the existing code to deal with a change like the one I am
suggesting, than it will be for future programmers to deal with the
confusion caused by not making the change. This is over and above the
fact that there will be much more code 5 years from now (we all hope!).
Take the example of Macsyma (or Spire or Kee or any other large 'old
time but still in use' Lisp program). What if this change breaks one of
them? We have to weigh that with the cost of propagating past confusion
by making apply and friends do conversion. But the people who maintain
systems like Macsyma and KEE are likely much higher Z programmers than
people who are writing new code. It probably won't be real hard for
these old time people to make this change. It is more likely that the
new lisp programmers will get confused and write bad code. I supect
people will write
(squirrel-function-away-1 '(lambda (x) ..))
(squirrel-function-away-2 #'(lambda (x) ..))
(funcall (fetch-function-1) (some-data))
(funcall (fetch-function-2) (some-data))
Since both 'functions', when they are fetched and funcalled will work,
people won't notice that the one isn't compiled. When and if they do
notice, it may take them a long time to understand why they are losing
this way.
∂02-Jun-87 1219 edsel!kent-state!eb@navajo.stanford.edu PATHNAME-SYMBOL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jun 87 12:19:07 PDT
Received: by navajo.stanford.edu; Tue, 2 Jun 87 12:14:59 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA13431; Tue, 2 Jun 87 11:53:27 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA08307; Tue, 2 Jun 87 11:53:18 PDT
Date: Tue, 2 Jun 87 11:53:18 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706021853.AA08307@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 1 Jun 87 23:45 EDT <870601234525.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: PATHNAME-SYMBOL
Date: Mon, 1 Jun 87 23:45 EDT
From: David A. Moon <navajo!Moon@STONY-BROOK.SCRC.Symbolics.COM>
Line-Fold: No
I'd say the succinct form of this point is that
strings preserve the case that you type in, but symbols don't, they
force to uppercase. This doesn't affect me, since I don't enjoy a file
system with case-sensitive file names, but it affects a lot of people.
I don't enjoy a file system with case-sensitive names, but I seem to
be stuck with it! Our VMS users like to be able to type (load 'foo),
though.
I think you've made a better case for eliminating the coercion of
symbols to strings, rather than making a special case restriction
against using a symbol as a string to be coerced to a pathname. You
have also made a case for making the boolean falsehood value be
something other than a symbol. Making this special case restriction
against symbols as pathnames is treating the symptom and not the
disease.
∂03-Jun-87 0729 gls@Think.COM ***BALLOT *** PART 1 *** My reply
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:29:40 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:31:54 EDT
Date: Wed, 3 Jun 87 10:29 EDT
From: Guy Steele <gls@Think.COM>
Subject: ***BALLOT *** PART 1 *** My reply
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870529-212725-1304@Xerox>
Message-Id: <870603102930.2.GLS@BOETHIUS.THINK.COM>
Date: 29 May 87 21:27 PDT
From: Masinter.pa@xerox.com
Please vote on the following issues which are open. "Release" means to
release the document to X3J13 for discussion & voting.
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[X] Release as is [ ] Comments follow in mail to cl-cleanup
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
AREF-1D (Version 1)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [X] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
IF-BODY (Version 5)
BALLOT: [X] Release as is [ ] Wait for version that SEF and KMP agree is
"fair".
IGNORE-ERRORS (Version 3)
BALLOT: [X] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [X] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
∂03-Jun-87 0731 gls@Think.COM DO-SYMBOLS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:31:42 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:34:03 EDT
Date: Wed, 3 Jun 87 10:31 EDT
From: Guy Steele <gls@Think.COM>
Subject: DO-SYMBOLS
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
Message-Id: <870603103149.3.GLS@BOETHIUS.THINK.COM>
I favor DO-SYMBOLS:ALLOWED, except that I would like to have
the following issue addressed: if duplicates are allowed, it
may admit an implementation that would not terminate in the
situation where each of two packages USEd the other? Do we
need a provision that DO-SYMBOLS must terminate, at least
for cases where the body does not aletr the packages involved?
--Guy
∂03-Jun-87 0733 gls@Think.COM ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:33:21 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:35:51 EDT
Date: Wed, 3 Jun 87 10:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870529-224247-1345@Xerox>
Message-Id: <870603103338.4.GLS@BOETHIUS.THINK.COM>
∂03-Jun-87 0749 gls@Think.COM June X3J13 meeting
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:48:54 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:48:46 EDT
Date: Wed, 3 Jun 87 10:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: June X3J13 meeting
To: MATHIS@ada20.isi.edu
Cc: cl-cleanup@sail.stanford.edu
Message-Id: <870603104633.8.GLS@BOETHIUS.THINK.COM>
I regret that for personal and business reasons I will
be out of town on the days of the June meeting, and
therefore cannot attend. Thinking Machines will send
an alternate representative.
--Guy
∂03-Jun-87 0809 gls@think.com Transitivity of coercions
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 08:09:29 PDT
Received: from THINK.COM by navajo.stanford.edu with TCP; Wed, 3 Jun 87 08:06:27 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 11:11:12 EDT
Date: Wed, 3 Jun 87 11:09 EDT
From: Guy Steele <gls@think.com>
Subject: Transitivity of coercions
To: edsel!kent-state!eb@navajo.stanford.edu,
navajo!cl-cleanup%sail@navajo.stanford.edu
Cc: gls@think.com
In-Reply-To: <8706012127.AA07224@kent-state.edsel.uucp>
Message-Id: <870603110900.0.GLS@BOETHIUS.THINK.COM>
Note that an explicit decision was made early in the design of CL
not to make all coercions transitive. For example, symbols
coerce to strings (for string functions), and strings are sequences
(and so can be mixed with other sequence types), but symbols are
not sequences.
If we cannot have consistency, let us then have consistency of
inconsistency. (Also known as, "This screw-up was good enough
for grampa, and it's good enough for me!")
--Guy
∂03-Jun-87 0926 gls@Think.COM People's names :-)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 09:26:28 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 12:29:08 EDT
Date: Wed, 3 Jun 87 12:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: People's names :-)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870603122658.3.GLS@BOETHIUS.THINK.COM>
A proposed standard for establishing naming standards for CL-CLEANUP proposals
Any message sent to CL-CLEANUP whose subject line consists solely of the
word "AXOLOTL" (in all upper case, possibly with surrounding whitespace)
may contain lines of the form
#REWRITE "xxx" => "yyyyy" comment
where xxx and yyyyy may be any strings. Such a line specifies that
henceforth in a CL-CLEANUP proposal any word-delimited substring "xxx"
of the proposal shall be replaced by "yyyyy". The comment may be any text
(possibly empty).
Masinter can collect these strings and use a software tool to apply them
all to each proposal as it is sent out. Rewrite rules shall be ordered,
first according to the timestamp of the message defining them (earliest
first), secondarily according to alphabetical order of sender (to break
timestamp ties), and lastly according to the order in which the rules
appear in the message (in case a message defines more than one rewrite
rule). When each rule is applied to a message, the leftmost occurrence
of "xxx" is located and replaced by "yyyyy"; the rule is then applied
again only to the remaining unsearched text, not to "yyyyy" or the text
that precedes it. This allows a rule that rewrites "loser" into
"incredible loser" to avoid infinite recursion.
A rule that rewrites a person's name into another form is automatically
adopted when proposed by that person unless vetoed by a 2/3 majority
of CL-CLEANUP. When proposed by another person it can be adopted only
after a show of 2/3 support. Any other rewrite rule is included or
not at the discretion of Masinter unless overridden by 2/3 vote.
For example (note that the following examples do not actually take
effect because the subject line of this message is not "AXOLOTL"):
#REWRITE "KMP" => "Pitman" Needs 2/3 vote to take effect unless
KMP should propose it himself
#REWRITE "GLS" => "Steele"
#REWRITE "mantissa" => "significand"
#REWRITE "that bagbiter Quux" => "that remarkable fellow Steele"
--Quux
P.S. Other extensions suggest themselves. For example, a line
of the form #FLUSH "xxx" in any message whose header contains
":-)" could mean that any message containing "xxx" should be
killed by the mailer at SAIL and not distributed to CL-CLEANUP
at all.
#FLUSH "#REWRITE"
∂03-Jun-87 1101 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 11:01:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 162940; Wed 3-Jun-87 14:00:15 EDT
Date: Wed, 3 Jun 87 14:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DO-SYMBOLS
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870603103149.3.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603140012.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Jun 87 10:31 EDT
From: Guy Steele <gls@Think.COM>
I favor DO-SYMBOLS:ALLOWED, except that I would like to have
the following issue addressed: if duplicates are allowed, it
may admit an implementation that would not terminate in the
situation where each of two packages USEd the other?
I don't think this is a problem, since using a package does not
inherit symbols that are -accessible- to that package, only
symbols that are -exported- by that package.
∂03-Jun-87 1154 KMP@STONY-BROOK.SCRC.Symbolics.COM People's names :-}
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 11:54:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163006; Wed 3-Jun-87 14:53:19 EDT
Date: Wed, 3 Jun 87 14:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: People's names :-}
To: RPG@SAIL.STANFORD.EDU
cc: gls@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@sail.stanford.edu
In-Reply-To: <870603122658.3.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603145314.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
There seems to be some bug in the SAIL mailer. I received the following
piece of mail, which was apparently not intended for me (or anyone on
CL-Cleanup, for that matter).
Please fix the mailer to prescan the text of messages and to make any
suggested improvements in itself -prior- to sending the mail in which
it reads about said improvements so that it can take advantage of those
improvements at the earliest opportunity.
Please be sure the mailer does not try to re-read the suggestion after
improving itself, however. This will avoid embarrassing halting problems
that could result from the improvement changing its understanding of the
suggestion.
-----
Date: Wed, 3 Jun 87 12:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: People's names :-)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870603122658.3.GLS@BOETHIUS.THINK.COM>
[text of message omitted]
∂03-Jun-87 1332 gls@Think.COM DO-SYMBOLS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 13:31:51 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 16:31:30 EDT
Date: Wed, 3 Jun 87 16:29 EDT
From: Guy Steele <gls@Think.COM>
Subject: DO-SYMBOLS
To: Moon@stony-brook.scrc.symbolics.com, gls@think.com
Cc: cl-cleanup@sail.stanford.edu, gls@think.com
In-Reply-To: <870603140012.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870603162917.0.GLS@BOETHIUS.THINK.COM>
Date: Wed, 3 Jun 87 14:00 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Wed, 3 Jun 87 10:31 EDT
From: Guy Steele <gls@Think.COM>
I favor DO-SYMBOLS:ALLOWED, except that I would like to have
the following issue addressed: if duplicates are allowed, it
may admit an implementation that would not terminate in the
situation where each of two packages USEd the other?
I don't think this is a problem, since using a package does not
inherit symbols that are -accessible- to that package, only
symbols that are -exported- by that package.
Right. Sorry. So suppose each of two packages uses the other,
and each happens to export the same symbol?
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B:ASYM B)
(USE-PACKAGE B A)
(DO-ALL-SYMBOLS (X B) (PRINT X)) ;will this print ASYM once, twice,
; an infinite number of times, or what?
--Guy
∂03-Jun-87 1906 Moon@STONY-BROOK.SCRC.Symbolics.COM DO-SYMBOLS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 19:05:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163448; Wed 3-Jun-87 22:04:49 EDT
Date: Wed, 3 Jun 87 22:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DO-SYMBOLS
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870603162917.0.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603220443.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Jun 87 16:29 EDT
From: Guy Steele <gls@Think.COM>
So suppose each of two packages uses the other,
and each happens to export the same symbol?
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B:ASYM B)
(USE-PACKAGE B A)
(DO-ALL-SYMBOLS (X B) (PRINT X)) ;will this print ASYM once, twice,
; an infinite number of times, or what?
DO-SYMBOLS:ALLOWED proposes to allow it to print ASYM once or twice, the
way I read it. I don't see how it could print it an infinite number of
times. (package-use-list (find-package 'a)) has no effect on
(package-external-symbols (find-package 'a)), hence should have no effect
on (do-symbols (x b) ...). Or are you saying that the specification
should be loosened up to the point where do-symbols is allowed to
recurse on packages used, and then only look at a subset of the symbols
in those packages?
Nit picking: I assume you meant (DO-SYMBOLS (X B) (PRINT X)) rather
than (DO-ALL-SYMBOLS (X B) (PRINT X)). I have no idea how many times
the latter should print ASYM, before it returns the value of B, except
that it shouldn't be an infinite number.
package-external-symbols is missing from the Common Lisp language for
some unfathomable reason, but you can define it in terms of do-external-symbols.
The example didn't run until I changed B:ASYM to B::ASYM.
End of nit picking: Does this mean the DO-SYMBOLS issue file needs to be
beefed up to discuss these issues, or are you and I just rambling while
waiting for our Thinking Machines (TM) central nervous system prosthetics
to be installed?
∂03-Jun-87 2038 FAHLMAN@C.CS.CMU.EDU PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 20:38:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Jun 87 23:37:15-EDT
Date: Wed, 3 Jun 1987 23:37 EDT
Message-ID: <FAHLMAN.12307700341.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: edsel!kent-state!eb@λnavajo.stanford.edu (Eric Benson)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: PATHNAME-SYMBOL
In-reply-to: Msg of 2 Jun 1987 14:53-EDT from edsel!kent-state!eb at navajo.stanford.edu (Eric Benson)
I think you've made a better case for eliminating the coercion of
symbols to strings, rather than making a special case restriction
against using a symbol as a string to be coerced to a pathname. You
have also made a case for making the boolean falsehood value be
something other than a symbol. Making this special case restriction
against symbols as pathnames is treating the symptom and not the
disease.
Treating the symptom rather than the disease is often the best way to
keep the patient alive. Let's fix what we can and think about more
extensive redesigns later.
-- Scott
∂03-Jun-87 2104 FAHLMAN@C.CS.CMU.EDU General strategy
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:04:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Jun 87 23:56:39-EDT
Date: Wed, 3 Jun 1987 23:56 EDT
Message-ID: <FAHLMAN.12307703872.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: General strategy
Before I start voting and commenting on specific issues, I'd like to
raise a point about our general strategy.
On important issues, where there is real disagreement within the cleanup
committee or where the issue is so critical that all sides must be
carefully explained, it is important that we present the issue with
multiple proposals and that the choosing is done by X3J13 as a whole.
On the other hand, a lot of these issues are trivial little things that
need to be cleaned up one way or another. I believe that X3J13 and the
Common Lisp community as a whole want these to be resolved without a lot
of needless agonizing, and they want this committee to provide the
leadership to get that job done. If there are two or three solutions to
some issue that differ only in "aesthetics", we on the cleanup committee
should converge on one solution, propose it, and endorse it.
We shouldn't say, "Well, we could do A and then again we could B, but
someone suggeted C and that's OK too." Instead, we should say, "We
propose A." In the discussion section we should say, "Solutions B and C
were discussed, but the cleanup committee has settled on A as the best
solution." If we send multiple-choice proposals to X3J13 on trivial
issues where it doesn't matter, the discussion will focus on those
stupid things and much more important issues will be neglected.
A number of the proposals currently offer useless options of this kind,
either as actual choices to be voted on or as variations suggested in
the discussion section. We should try to resolve these among ourselves
rather than leaving them hanging. I'm not worried about people
following us blindly -- X3J13 seems to have enough sharp and contentious
people on it to prevent any abuse of this power.
-- Scott
∂03-Jun-87 2124 FAHLMAN@C.CS.CMU.EDU Ballot, parts 1 and 2
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:24:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:23:54-EDT
Date: Thu, 4 Jun 1987 00:23 EDT
Message-ID: <FAHLMAN.12307708833.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Ballot, parts 1 and 2
ADJUST-ARRAY-DISPLACEMENT (revision 1)
[ ] Release as is [x] Comments follow in mail to cl-cleanup
; OK in substance, but I'd like an edit to the discussion section.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
; Or, if whoever proposed it insists, bring it out with a negative
; recommendation and let it be defeated once and for all.
ROW-MAJOR-AREF (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; I prefer KMP's version 2 with the name change.
ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; But first proofread the "adoption cost" section.
DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [x] Other:
comments follow in mail to cl-cleanup
FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; Proofread "Conversion Cost" section.
IF-BODY (Version 5)
BALLOT: [ ] Release as is [ ] Wait for version that SEF and KMP agree is
"fair". [ ] Comment follows.
IGNORE-ERRORS (Version 3)
BALLOT: [x] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
; Eliminating the question about KMP's priorities.
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [x] Table, pending possible new proposal [ ] Comments
follow in mail to cl-cleanup
PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
; I'm not going to vote on anything not yet submitted or discussed. I'm
; not likely to favor any proposal that deviates from deterministic
; left-to-right evaluation, however.
PROMPT-FOR (revision 1)
BALLOT: [x] Table, pending possible new proposal [ ] Comments follow in
mail to cl-cleanup
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else
[x] Undecided
; Someone needs to take the lead in boiling this down to a single
; coherent proposal.
SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
; ??? I don't seem to have a recent version of this. I'd like a
; redesign of the whole font/bits business, but might support a quick
; fix in the meantime.
∂03-Jun-87 2135 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:35:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:34:58-EDT
Date: Thu, 4 Jun 1987 00:34 EDT
Message-ID: <FAHLMAN.12307710848.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
In-reply-to: Msg of 30 May 1987 00:13-EDT from Masinter.pa at Xerox.COM
I support this proposal and have no problem with releasing it as-is,
except for the form in which Moon's comments are included at the end.
As it stands, this is one of those proposals that seems to say, "Let's
do A, but then again we might want to do B."
Unless Moon wants to push the alternative he raises, we should either
drop this comment or say something like the following:
"Moon pointed out that the Symbolics system currently does ..., and that
this is an equally viable alternative. However, the committee has
decided to stick with the proposal as described above."
If Moon strongly favors the alternative he describes, I could support
that as well. I just think we need to pick one or the other. This is
one of those cases where a clear and definite stand by the
cleanup committee would prevent the larger committee from getting bogged
down in needless details.
∂03-Jun-87 2145 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 21:44:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:44:18-EDT
Date: Thu, 4 Jun 1987 00:44 EDT
Message-ID: <FAHLMAN.12307712547.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 2)
In-reply-to: Msg of 30 May 1987 00:16-EDT from Masinter.pa at Xerox.COM
I support DO-SYMBOLS-DUPLICATES:ALLOWED.
I don't think we should present X3J13 with two alterantives on a dumb
issue like this. If someone really feels strongly about the keyword
version and wants to produce a correct and complete version of the
keyword proposal in the next couple of days, I would be willing to go
along with that instead. But in any case, I think we should decide
among ourselves and only bring one proposal out of this committee.
If we do go with a keyword version, I feel rather strongly that the
default must be to allow duplicates. In most cases, the issue of
duplicates really doesn't matter, and we don't want to saddle users with
a much more expensive default.
-- Scott
∂03-Jun-87 2201 FAHLMAN@C.CS.CMU.EDU IF-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 22:01:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:00:44-EDT
Date: Thu, 4 Jun 1987 01:00 EDT
Message-ID: <FAHLMAN.12307715536.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY
I'm willing to go along with releasing KMP's latest revision of IF-BODY,
even though it doesn't properly argue the case that manufacturers should
provide reasonable portability tools before using non-portability as an
argument for changing the language.
I am confident that this proposal will be defeated and then we'll be
done with it. If I am wrong, I can probably live with that. (Of
course, any CMU programmers caught using extended-IF would get a "mild"
electric shock to remind them that legal Common Lisp is not necessarily
acceptable Common Lisp.)
What is important to me is not that we hold up this particular issue,
but that in the future we adopt an adversarial system for putting
together proposals on which we cannot reach a consensus. Nobody should
be put in the position of having to summarize a position he doesn't
agree with; it's a very difficult, thankless task for the summarizer,
and the opposition is likely to feel screwed anyway. Each side should
get some space in which to argue its case, and nobody should edit the
result.
-- Scott
∂03-Jun-87 2232 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 22:32:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:31:53-EDT
Date: Thu, 4 Jun 1987 01:31 EDT
Message-ID: <FAHLMAN.12307721211.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Msg of 30 May 1987 00:18-EDT from Masinter.pa at Xerox.COM
There seem to be three positions here:
1. The "maximally clean" proposal, in which FUNCALL, APPLY, and the
built-in functions that take functional args would take only true
functions and it would "be an error" to pass either of these a lambda
expression or a symbol.
2. The "maximally compatbile" proposal currently reflected by
FUNCTION-TYPE:REDEFINE.
3. The "maximally Macsyma" proposal, which is like 2 but would also
require that SYMBOL-FUNCTION take a symbol or lambda and return it
unchanged.
I actually favor option 1, though I think that we must be up-front about
the incompatibilities it introduces. Several others seem to share this
view.
It might be hard to get the majority of X3J13 to agree to option 1,
however, since a lot of those people are more worried about preserving
existing code than about cleanliness and consistency. If we want to
resolve this issue in a hurry, pushing option 2 might be the way to go.
Moon has been the most vocal advocate of option 2 within the cleanup
committee. Personally, I could live with this, though I prefer option
1.
So far, only KMP has argued in favor of option 3. This does not reflect
the status quo in many implementations, and some of us view it as a step
backwards.
It would be great if we could reach some internal consensus on this
issue and present a recommendation from the whole cleanup committee. If
this is impossible, we should write this up as a two-option or
three-option proposal and let X3J13 fight it out. I don't think we
should sit on this indefinitely waiting for someone's mind to change or
break it up into little pieces -- either move will just guarantee that
this remains unresolved for the forseeable future.
If people are comfortable with releasing the current version, I can go
along with that in priciple, but the presentation needs to be cleaned up.
I will be happy to do some of the work of redrafting this proposal, but
can't do this without understanding where the committee members stand:
what they favor, and what they would agree to.
-- Scott
∂03-Jun-87 2238 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 22:37:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:37:10-EDT
Date: Thu, 4 Jun 1987 01:37 EDT
Message-ID: <FAHLMAN.12307722170.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
In-reply-to: Msg of 30 May 1987 00:22-EDT from Masinter.pa at Xerox.COM
I support this proposal and support releasing it as-is, except for the
next to last paragraph about NIL. Another dangling issue, and this time
it seems like the sentence, "The cleanup committee supports this change"
refers to the exclusion of NIL.
I don't care whether we decide that NIL should be allowed or disallowed,
but we should decide on one or the other and say so clearly, not just
mumble on both sides of the issue with no resolution.
-- Scott
∂04-Jun-87 0852 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
When Clinger and I proposed this cleanup, it was the maximally clean
version, and that is the one I support. On the other hand, I believe that
there is little reason to actually press for the maximally clean version.
In some sense, all of us are trying to ``spread the word'' about Lisp,
trying to get currently non-Lisp programmers to switch. We could do this
if there were some way for mainstream computing to be done in Lisp.
With a language like Common Lisp this is not possible - it is too big
and it is growing. What we could have hoped to accomplish with this
cleanup is a first step towards establishing a continuum of Lisps from
Scheme up through Common Lisp. Even if we were to adopt this change, the
period until we had the continuum would be lengthy.
I don't think we can win this game quickly given the time constraints
and the current state of Common Lisp. We continue to argue about the
filigrees.
I believe that we ought to minimally clean up Common Lisp and rapidly
move on to the next great Lisp language design.
-rpg-
∂04-Jun-87 1742 Masinter.pa@Xerox.COM Format revisited
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 17:42:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:25:35 PDT
Date: 4 Jun 87 17:25 PDT
From: Masinter.pa@Xerox.COM
Subject: Format revisited
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870604-172535-1480@Xerox>
Summarizing the ballots is slow going. I hope to be done tomorrow and to
mail out some revisions.
Below is a minor revision of the style sheet which incorporates a couple
of suggestions.
Note that the hardcopy of the issues to x3j13 (and the internal copies I
deal with) have font and paragraph control, but I have no simple way of
mailing them out in that form. However, I'd suggest you not worry about
formatting or grinding of paragraphs.
!
Format for proposals to "clean up" Common Lisp.
Revision 9 - 4-Jun-87
>>Replace the text in italics (double inverted angle-brackets). Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.<<
Issue: >>A short descriptive label, which starts with a name which
occurs in the index of CLtL, and be a suitable symbol in the Common Lisp
style, e.g., CDR-TERMINATION. .<<
References: >>The pages of CLtL which describe the feature being
discussed, or other references..<<
Category: >>One or more of: CLARIFICATION - proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE - Proposal for an
incompatible change to the language. ADDITION - Proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission, and author and date of
subsequent revisions.<<
Problem description: >>Describe the problem being addressed -- why is
the current situation unclear or unsatisfactory? Avoid describing the
proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details. Avoid arguing for the proposal here, just describe it.<<
Test Case: >>When possible, give a sample of Common Lisp code that
illustrates the issue.<<
Rationale: >> A brief argument for the proposal. (If more than one
proposal is listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice: >>Do some/many/no Common Lisp implementations already
work this way? Survey independent Common Lisp implementations -
preferably three or more.<<
Adoption Cost: >>What is the cost to implementors of adopting the
proposal? How much implementation effort is required? Is public-domain
code available? For pervasive changes, can the conversion be
automated?<<
Benefits: >>What is better if the proposal is adopted? How serious is
the problem if just left as it is? <<
Conversion Cost: >>For incompatible changes, what is the cost to users
of converting existing user code? To what extent can the process be
automated? how?<<
Esthetics: >>How does this proposal affect the simplicity of the
language, ease of learning, etc.<<
Discussion: >> Additional arguments, discussions, endorsements,
testimonials, etc. should go here. A blow-by-blow account of debates is
not necessary. <<
∂04-Jun-87 1742 Masinter.pa@Xerox.COM AREF-1D (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 17:42:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:25:58 PDT
Date: 4 Jun 87 17:25 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870604-172558-1481@Xerox>
Status: Ready for release.
I made the edits before seing Kent's revision, so I went ahead and
merged his version and mine. I will mail this version out to X3J13 next
week (unless I hear objections.)
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
4-Jun-87, Version 3 by Masinter (very minor editorial
work)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying arity.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF which allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators which allow users to exploit that order. ROW-MAJOR-AREF is
a useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops which had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations which already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something which they already have
inefficient access to.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee supports this enhancement.
∂04-Jun-87 1742 Masinter.pa@Xerox.COM Merging of committees
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 17:42:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:27:46 PDT
Date: 4 Jun 87 17:27 PDT
Sender: Masinter.pa@Xerox.COM
Subject: Merging of committees
To: cl-cleanup@Sail.stanford.edu
From: Larry Masinter <Masinter.PA@Xerox.COM>
Message-ID: <870604-172746-1483@Xerox>
On the subject of the possible merger of the cleanup committee and the
error or compiler committees:
I am very much opposed to merging other committees in with the Cleanup
Committee. Even if there is substantial, or even total, overlap of the
committees (e.g., even if everyone on the Compiler Committee is a member
of the Cleanup Committee), the committees have different charters, sets
of issues, etc.
If the Error committee needs some help and the compiler committee needs
some new members, we individually can try to help fix those things.
I also am opposed to taking smaller issues which rightfully belong to
those other committees and putting them thru cl-cleanup.
For example, I am opposed to the CLEANUP committee releasing
Ignore-errors. If Kent thinks it is a good idea to get IGNORE-ERRORS
out, then let that be the report and proposal of the Error committee.
Kent can even report that the Cleanup committee likes the idea, but it
should come as a report and recommendation of the error committee.
I would like to see separate committees (again, even if they
substantially or totally overlap with this one) deal with the issues of
compilation and declarations, the issue of signalling and also the
myriad set of changes where "is an error" might turn into "signals an
error" and where "signals an error" might turn into "signals a FROB
error".
I'm willing to join the error committee and the compiler committee if
its necessary to help get them off the ground or they seem to lack
critical mass, although I'm not yet convinced that it is necessary.
Larry
∂04-Jun-87 1856 MATHIS@ADA20.ISI.EDU
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87 18:56:05 PDT
Date: 4 Jun 1987 18:55-PDT
Sender: MATHIS@ADA20.ISI.EDU
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 4-Jun-87 18:55:20.MATHIS>
Larry, I just sent you a set of mailing labels for x3j13 as you
requested. They should come by express mail on Friday.
To all of the committee -- keep up the good work.
Bob
∂04-Jun-87 1925 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87 19:25:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164454; Thu 4-Jun-87 22:24:02 EDT
Date: Thu, 4 Jun 87 22:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870604-172558-1481@Xerox>
Message-ID: <870604222355.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Change "arity" to "rank" to be consistent with standard Common Lisp
terminology. Otherwise fine.
∂04-Jun-87 1933 KMP@STONY-BROOK.SCRC.Symbolics.COM Merging of committees
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87 19:32:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164465; Thu 4-Jun-87 22:31:13 EDT
Date: Thu, 4 Jun 87 22:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Merging of committees
To: Masinter.PA@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <870604-172746-1483@Xerox>
Message-ID: <870604223106.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 4 Jun 87 17:27 PDT
From: Larry Masinter <Masinter.PA@Xerox.COM>
... I am opposed to the CLEANUP committee releasing IGNORE-ERRORS.
If Kent thinks it is a good idea to get IGNORE-ERRORS out, then let
that be the report and proposal of the Error committee. Kent can
even report that the Cleanup committee likes the idea, but it should
come as a report and recommendation of the error committee. ...
I disagree. The Error Committee is responsible for preparing a complete
proposal. The Cleanup is responsible for making minor patches. This is a
minor patch which is contingent on the Error Committee -not- doing something.
It would be inappropriate for the Error Committee to make conflicting
recommendations. It is not inappropriate for two groups with (as you
yourself said) different goals to make conflicting recommendations.
I completely agree that the committees should not be merged. Although
there is a gray area in all of this where X3J13 adopts various proposals
of other committees and it may be appropriate for the Cleanup committee
to then take over the job of minor corrections to what at that point
amounts to a normal part of the language. We can cross that bridge when
we come to it, though; it's certainly no relation to what's going on at
this point in any of the subcommittees I know of.
∂05-Jun-87 1808 Masinter.pa@Xerox.COM FORMAT-OP-C (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 18:08:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 15:05:51 PDT
Date: 5 Jun 87 15:04 PDT
From: Masinter.pa@Xerox.COM
Subject: FORMAT-OP-C (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-150551-2556@Xerox>
I'm not sure it wouldn't be simpler to make the use of ~C on characters
with non-zero BITS (and FONT?!) an error, rather than attempting to
leave it unspecified. I suppose if we can get up a vote to remove BITS
and FONT from the standard, it is moot.
The discussion of the stream-dependent behavior confused bytes with
characters in an unfortunate way. I rewrote that part of it to be what I
believe the truth is; I'm not sure if you agree, however. My notion was
that write-char always writes a single character; writing a
single-character causes multiple bytes to be written. However, a
subsequent read-char of the same stream should produce EQL characters as
were given to write-char. The only thing which is
stream/operating-system dependent is the mapping of characters to bytes.
When I thought about *that* some more, I decided it was really a
clarification about WRITE-CHAR and not about FORMAT ~C, so I moved the
whole paragraph about clarifying WRITE-CHAR to the discussion section.
This proposal is now very short.
!
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Versions 2,3 by Pitman (merge in suggestions)
5-Jun-87, Version 4 by Masinter, minor copy-editing
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should be
culturally compatible with the host environment." This description is
not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose:
some implementations have (FORMAT NIL "~C" #\Space) => "Space" rather
than " ".
Since the behavior of ~A is also vague on characters (a separate
proposal addresses this), the only way to safely output a literal
character is to WRITE-CHAR; currently, FORMAT does not suffice.
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. (This proposal
leaves the behavior of ~C with non-zero bits incompletely specified.)
For example, the description of the ~C format directive on p389 of CLTL
might read:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Test Case:
(EQUAL (FORMAT NIL "~C" #\Space) " ")
Rationale:
This was probably the intent of the Common Lisp designers.
It makes things clear enough that programmers can know what to expect in
the normal case (standard characters with zero bits).
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and ~:C
equivalently or very similarly.
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would require an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable. As things
stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of "~C"
and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as a
simplification.
Discussion:
The cleanup committee supports this clarification.
The original version of this proposal (which tried to make WRITE-CHAR
and ~C identical in all cases) prompted the following comment:
I believe the error in CLtL is that it was not stated explicitly
that the "implementation-dependent abbreviated format" applies only
to characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as write-char for characters
with zero char-bits. I don't think we want to require ~C and
write-char to do the same thing for characters with bits.
It may be necessary to clarify that WRITE-CHAR puts only one character
on its argument stream, such that a subsequent READ-CHAR of the same
file would read only one character. (Of course, in some operating
systems or for some devices, WRITE-CHAR of a single character might
cause multiple bytes to be written, substituted, escaped, quoted or the
like.)
∂05-Jun-87 1809 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 18:08:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 15:30:08 PDT
Date: 5 Jun 87 15:30 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 22 Apr 87 15:14 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870605-153008-2585@Xerox>
I think the reason that ASSOC-IF, RASSOC-IF and friends do not have :KEY
arguments is that ASSOC-IF is equivalent to FIND-IF :KEY #'CAR and
RASSOC-IF is FIND-IF :KEY #'CDR. That is, the way I think of these
functions, they already have a KEY argument, it is just that the KEY is
already implicitly specified by the function name.
I don't see any substantial advantage of expressiveness in this
proposal.
∂05-Jun-87 1809 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 18:09:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 16:10:52 PDT
Date: 5 Jun 87 16:10 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-161052-2627@Xerox>
I made the discussion less wishy-washy by saying we rejected disallowing
NIL. I made some edits to fix typos various people pointed out. I fixed
the "grinding".
Status: Ready for release.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL. That is:
If, following an &key, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place. In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in. If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.
The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered but rejected a proposal to exclude NIL
as a legal indicator. It might catch some errors, but is otherwise an
odd restriction.
The cleanup committee supports this change.
∂05-Jun-87 2113 KMP@STONY-BROOK.SCRC.Symbolics.COM Sigh -- More procedure
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jun 87 21:12:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 165549; Sat 6-Jun-87 00:12:11 EDT
Date: Sat, 6 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sigh -- More procedure
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870606001157.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm sorry for the length of this message. It treats an issue which
I thought we'd settled before when Fahlman edited a proposal and
forgot to change its status back to internal, but in my view that
agreement has been violated again an I want to re-open the issue:
My votes are significantly based on the wording of a proposal, not just
their spirit. My guess from their behavior is that many of the others on
this list do likewise. To me, no other choice is possible because this
same rigor is the manner in which CLtL gets interpreted by users and
we accept the fact that every word and punctuation mark could potentially
make a difference.
Earlier this week, I allocated a long evening to carefully re-read all
the relevant mail leading up to the proposals upon which we were asked
to vote. I allocated this time at your request, believing that this was
the final vote and that extreme care was in order. Now you've changed
the proposal and marked some things ready for release and/or falsely
claimed that the cleanup committee endorses this proposal, which in fact
the cleanup committee has not seen.
When I worked on the student newspaper at MIT, we had a policy that we
didn't reply to letters to the editor; the reason was that the paper
always had the opportunity to get in the last word and this wasn't fair
in a forum which was supposed to promote open discussion. Likewise, we
have an informal rule that the moderator at X3J13 meetings should not
feel free to interject comments in between designating queued speakers
-- since he obviously has an unfair opportunity to say more than is
appropriate. I think it would be useful if we could agree that the
moderator here should follow the same conventions as everyone else in
either not being able to change things at the last minute.
I'm willing to be very liberal in my definition of "the last minute". I
consider that the line was drawn when you yourself said we were making a
final vote and that if people had been hesitating that this was the time
they should say something. I think it is inconsiderate for you to then
make further changes that cause me to feel compelled to spend more time
when I've already gone for broke on my budgeted time at your own
suggestion. I feel that since you have the last contact with the documents
between now and when they are seen by X3J13, that you have a moral
obligation to resist changing them in that interval or to explicitly admit
that another full round of voting is in order.
I was very hesitant to send out my change to AREF-1D and FORMAT-OP-C
proposals at the last minute, but it seemed clear that the vote was not
going to favor the existing versions so there seemed little harm in getting
an early start on the next voting cycle. In fact, even after making all
the desired changes, I carefully marked both of these to have been approved
only on previous passes so that people's votes would not be misconstrued.
This kind of care may seem silly, but I believe it to be important.
I would not have been and will not be disturbed if neither AREF-1D nor
FORMAT-OP-C is presented to X3J13 due to our having had too little time
to review the most recent proposals internally and re-vote.
I want it clear that I have expressed no opinion on:
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
FORMAT-OP-C (Version 4)
If either of these documents is distributed to X3J13 prior to my having
expressed an opinion that they are acceptable in their current form, I
will be upset. [If it is possible for me to accept either or both in the
current form, I'll try to do so to minimize work for all, but I can't
guarantee that.]
By the way, the top of your message about KEYWORD-ARGUMENT-NAME-PACKAGE
says:
``I made the discussion less wishy-washy by saying we rejected disallowing
NIL. I made some edits to fix typos various people pointed out. I fixed
the "grinding".''
In fact, you changed more than just the "Discussion" field. You changed
the Proposal field. I'm sure you meant to use the term generically and not
to specifically mislead me into looking only in the Discussion field to
see what you'd changed, but perhaps this illustrates why every word is so
important to me. One little difference (eg, the difference between "discussion"
and "Discussion") can really have a big effect.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM Re: Sigh -- More procedure
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:45:45 PDT
Date: 5 Jun 87 21:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Sigh -- More procedure
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sat, 6 Jun 87 00:11 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870605-214545-2882@Xerox>
I'm sorry Kent. In my rush to get things out to X3J13 and to respond to
the rather massive number of minor typos and corrections and remarks
that I recieved, I've been a bit sloppy about recording which sections
got edited in response to which remarks. One problem is that, as you say
yourself, people had been hesitating to say anything about proposals now
open up (at the last minute) with lots of comments on them; in many
cases, they are relevant and useful comments, and the only reasonable
thing to do is to address the comments in the proposal.
I will say that I don't (and didn't) intend to release documents to
X3J13 without there being some opportunity for objections by this
committee.
The "the cleanup committee endorses this ..." statements are of course
provisional. However, if we want to say that we endorse something by
consensus then I need to write it in the proposal itself. If the
proposal says "FOO and JOE like this proposal." and then we all agree,
and I edit it to say "we all agree", then, by your own rules, I'd have
to send it out again for yet another ballot since the wording changed.)
I think we have a little more flexibility about wording than was
available CLtL because the wording of these proposals are in fact
subject to the interpretation of the committee that actually writes the
standards document. That is, we're specifying intent and not exact
wording.
I will be more careful identifying the changes to proposals, and my use
of "Ready for release". (I don't expect to send out any documents to
CL-CLEANUP with the annotation "Ready for release" because, if you've
already seen it and voted on it, then I don't need to send it out again,
do I?)
I'm finally done going through all of the ballots and suggestions and
what have you. I will mail out a new status report shortly, and also
some revised versions of some of the proposals.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:48:23 PDT
Date: 5 Jun 87 21:48 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Message-ID: <870605-214823-2885@Xerox>
(This was prepared before Kent's angry note. I'm a little reluctant to
mail it out now, but I don't know what to do with it. I made the edits
in response to Kent's question, as well as changing the case of the lisp
words, changing revision to version, etc. I don't remember all of the
edits, but I spent quite a while on it.)
Rather than wait for some resolution of Kent's question about the
omission of the :DISPLACED-TO argument, I took the liberty of guessing
that adjusting a displaced-to array without setting the :displaced-to
meant that the result was displaced to the same place. I inserted rule 3
and renumbered the rules.
The previous version got lots of yes ballots. Any objections to this
one?
!
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: ADJUST-ARRAY (Steele p.297)
Category: Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
Version 2 by Masinter
Version 3 by Masinter, 5-Jun-87 (respond to comments)
Problem Description:
The interaction of ADJUST-ARRAY and displacement is insufficiently
specified in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Suppose we are adjusting array A, which is perhaps displaced to B before
the ADJUST-ARRAY call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate. Additional elements of A
are taken from the :INITIAL-ELEMENT. The use of :INITIAL-CONTENTS
causes all old contents to be discarded.
(2) A is not displaced before, but is displaced to C after. As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.
(3) A is displaced to B before and after the call (A is displaced to B
before the call, and the :DISPLACED-TO argument of ADJUST-ARRAY either
is ommitted or is B.) The dimensions of A are altered, and the contents
rearranged as appropriate. If :DISPLACED-INDEX-OFFSET is not specified
in the ADJUST-ARRAY call, it defaults to zero; the old offset is not
retained.
(4) A is displaced to B before the call, and is displaced to C after the
call. As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C). If
:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it
defaults to zero; the old offset (into B) is not retained.
(5) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :INITIAL-ELEMENT. However, the use of
:INITIAL-CONTENTS causes all old contents to be discarded.
If array X is displaced to array Y, and array Y is displaced to array Z,
and array Y is altered by ADJUST-ARRAY, array X must now refer to the
adjusted contents of Y. This means that an implementation may not
collapse the chain to make X refer to Z directly and forget that the
chain of reference passes through array Y. (Cacheing techniques are of
course permitted, as long as they preserve the semantics specified here
and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X. This error may be signalled
at the time of the adjustment, but this is not required.
Rationale:
This interaction must be clarified. This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here. Others
may do something random. [See discussion below.]
Adoption cost:
Some existing implementations may have to be changed, but adopting any
other model would be worse. Public-domain code implementing this model
is available from CMU.
Benefits:
Clarification of a situation that is currently not addressed by the
standard.
Conversion Cost:
This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works. Any
user code that cares about this issue probably already follows the
proposed model.
Discussion:
The cleanup committee supports this clarification.
Moon pointed out that the Symbolics system currently does this, except
for case (5) above. The Symbolics system never copies the contents of B
in this case; all elements are taken from the :initial-element. However,
the behavior in the proposal seems as justifiable to him, and the
cleanup committee decided to stick with the proposal as described above.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM AREF-1D (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:52:52 PDT
Date: 5 Jun 87 21:52 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-215252-2889@Xerox>
Besides changing arity-> rank and various whichs to thats, I think I
probably made some other minor edits, but didn't intentionally change
the meaning. However, I do remember trying to soften the feeling that
you had to know and want MacLisp's LISTARRAY and FILLARRAY for this to
be a good idea, and to take the blow-by-blow of who liked what in
previous versions out of the discussion. Note that the issue is still
called AREF-1D even those the proposal is ROW-MAJOR-AREF.
Status: Ready for release?
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial work)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something to which they already
have inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee supports this enhancement.
∂05-Jun-87 2209 Masinter.pa@Xerox.COM proposal format (version 10)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:54:55 PDT
Date: 5 Jun 87 21:54 PDT
From: Masinter.pa@Xerox.COM
Subject: proposal format (version 10)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-215455-2893@Xerox>
This version incorporates some minor comments.
!
Format for proposals to "clean up" Common Lisp.
Version 10 - 5-Jun-87
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name which
occurs in the index of CLtL, and be a suitable symbol in the Common Lisp
style, e.g., CDR-TERMINATION. .<<
References: >>The pages of CLtL which describe the feature being
discussed, or other references..<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE -- proposal for an
incompatible change to the language. ADDITION -- proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description: >>Describe the problem being addressed -- why is
the current situation unclear or unsatisfactory? Avoid describing the
proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details. Avoid arguing for the proposal here, just describe it.<<
Test Case: >>When possible, give a sample of Common Lisp code that
illustrates the issue.<<
Rationale: >> A brief argument for the proposal. (If more than one
proposal is listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice: >>Do some/many/no Common Lisp implementations already
work this way? Survey independent Common Lisp implementations -
preferably three or more.<<
Adoption Cost: >>What is the cost to implementors of adopting the
proposal? How much implementation effort is required? Is public-domain
code available? For pervasive changes, can the conversion be
automated?<<
Cost of non-adoption: >>How serious is it if nothing is done? <<
Benefits: >>What is better if the proposal is adopted? How serious is
the problem if just left as it is? <<
Conversion Cost: >>For incompatible changes, what is the cost to users
of converting existing user code? To what extent can the process be
automated? How?<<
Esthetics: >>How does this proposal affect the simplicity of the
language, ease of learning, etc.<<
Discussion: >> Additional arguments, discussions, endorsements,
testimonials, etc. should go here. A blow-by-blow account of debates is
not necessary. <<
∂05-Jun-87 2210 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:09:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:57:51 PDT
Date: 5 Jun 87 21:57 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
Message-ID: <870605-215751-2896@Xerox>
I think all I did was minor formatting changes (e.g., Defun => DEFUN,
Revision -> Version, SEF -> Fahlman, etc.) although it was a long time
ago today and I'm not 100% sure.
Status: Ready for release?
!
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Category: Omission.
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Versions 4,5 by Fahlman 11-Apr-87
Version 6 by Masinter 5-Jun-87
Problem Description:
Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
Flet.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
Two alternatives to the proposal were considered and rejected:
The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks. This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.
The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms. There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
However, eliminating the implicit block in DEFUN would be a significant
incompatible change. Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature. While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations. The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.
∂05-Jun-87 2235 Masinter.pa@Xerox.COM Re: proposal format (version 10)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:35:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:19:34 PDT
Date: 5 Jun 87 22:19 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: proposal format (version 10)
In-reply-to: Masinter.pa's message of 5 Jun 87 21:54 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <870605-221934-2920@Xerox>
The "proposal format" I mailed looks much better with fonts rather than
in plain ascii. However, since we prefer proposals in ascii rather than
formatted (or at least, I do) I am going to reformat it so that it looks
good with a simple fixed-pitch font, no italics, etc.
(I'm sorry to say that I looked at the without-formatting version for
the first time when I got the bounce back from the arpanet.)
∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:50:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:38:06 PDT
Date: 5 Jun 87 22:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-223806-2928@Xerox>
This one had just revision -> Version and KMP -> Pitman.
Status: ready for re-release! No ? about it.
!
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 at committee meeting 15-Mar-87
Version 3 Masinter 15-Mar-87
Version 4 by Fahlman, incorporate Dribble
Version 5 by Masinter, 29-May-87, revert to Version 3
Version 6 by Masinter, 5-Jun-87, minor formatting
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.
The cleanup committee supports this change as stated.
∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Revision 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:50:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:42:38 PDT
Date: 5 Jun 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Revision 3)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-224238-2931@Xerox>
This version has revision => version, KMP => Pitman, removal of first
person by deleting "to me".
Status: Version 3 released. Ready for re-release! (no ? about it).
!
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by KMP 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Masinter (normalize format) 15-Mar-87
Version 4 by Masinter 5-Jun-87
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to initializing it. More
importantly, though, DEFVAR is used by lots of users in every
implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious.
Discussion:
The cleanup committee supports this clarification.
∂05-Jun-87 2250 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 22:50:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:43:39 PDT
Date: 5 Jun 87 22:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-224339-2934@Xerox>
The subject of the previous message was wrong (it said Revision 3)
This version has revision => version, KMP => Pitman, removal of first
person by deleting "to me".
Status: Version 3 released. Ready for re-release! (no ? about it).
!
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by KMP 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Masinter (normalize format) 15-Mar-87
Version 4 by Masinter 5-Jun-87
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to initializing it. More
importantly, though, DEFVAR is used by lots of users in every
implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious.
Discussion:
The cleanup committee supports this clarification.
∂05-Jun-87 2349 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 23:49:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 23:28:48 PDT
Date: 5 Jun 87 23:27 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870605-232848-2962@Xerox>
Gregor said in his ballot that comments would follow, but I can't find
them. Did I miss them? I saw some notes about a more general facility
for accessors and constructors of lexical environments on the CLOS
mailing list, so I hoped I was on the mark by adding that to the
discussion section.
Kent asked that NIL be explicitly allowed for the null lexical
environment. I put that in.
Version 2 got lots of yes ballots.
Status: Ready for release?
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter (from Steele
list)
... 7-Apr-87, merged with other environment
argument issues
Version 2 29-May-87, by Masinter, extracted again
Version 3 5-Jun-87, by Masinter.
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that MACROLET, FLET and LABELS can shadow a SETF method; i.e., a
SETF method applies only when the global function binding of the name is
lexically visible.
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a users program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂06-Jun-87 0000 Masinter.pa@Xerox.COM ***READ ME FIRST ***Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 23:59:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 23:52:39 PDT
Date: 5 Jun 87 23:52 PDT
From: Masinter.pa@Xerox.COM
Subject: ***READ ME FIRST ***Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870605-235239-2975@Xerox>
This is not meant to go outside of this committee, although it will be
the source for a status report. My belief is that, while we may want to
mail out proposals ahead of time, there is no need to mail out the
status report early, we might have more to report by the meeting anyway.
**** NOTE ***** I intend to mail the proposals marked with a * (Ready
for release?) to mail to X3J13 by Wednesday of next week unless I hear
some objection. (I think I'm a little upset that Kent is got so mad at
me.)
If there is one issue we should debate about between now and the
meeting, I think it is FUNCTION-TYPE. We seem to have some agreement on
the core issue, and some disagreement on exactly how to proceed over the
issue of making FUNCALL (and MAPC) not take symbols. I think this is
one where we should bring the debate to the whole X3J13 once the issues
are laid out.
Normally, before I send one of these out I double check all of the
entries against all of the mail files to make sure that I've left
something out. However, I'm tired and its late, and I've only checked
them out to GET-SETF-METHOD-ENVIRONMENT.
In this document: EB = Benson, GLS = Steele, PC = Pavel Curtis, KMP =
Kent Pitman SEF = Scott Fahlman
[name/initials] position => person identified by name/initials voted
position on ballot.
[all] position => everyone who voted on this issue voted this way
position on ballot.
Withdraw = Place on hold pending resolution of comments already
received.
Proposal format (Version 10)
Needs re-formatting for non-fonted ascii
ready for release otherwise?
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Comments & edits after ballot.
Ready for release?
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
comments from Moon, JonL, SEF against current form
[EB, PC, SEF] Withdraw
Not ready for release
* AREF-1D (Version 4/5-jun-87)
(Add a new function for accessing arrays with row-major-index)
[all] Version 2 release as ROW-MAJOR-AREF
Ready for release?
* ASSOC-RASSOC-IF-KEY (Version 1/22-Apr-87)
(Extend ASSOC-IF, etc. to allow :KEY)
[EB, GLS, KMP] Release as is
[LMM] ASSOC-IF has CAR for KEY?
Ready for release?
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
* COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
(Version 4, submittted by SEF was withdrawn --
consider DRIBBLE as a separate issue)
Version 3 released.
Version 6 ready for re-release!
* DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 ready for re-release!
* DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Ready for release?
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
[EB, GK] DO-SYMBOLS:ALLOWED
[PC, Moon, LMM] something like :ADD-KEYWORD
In discussion, not ready for release
ENVIRONMENT-ARGUMENTS (Version 1)
Separated into other proposals.
Withdrawn.
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Not yet submitted.
* FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Ready for release?
* FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
Version 3 released.
Version 4 ready for re-release.
FORMAT-NEGATIVE-PARAMETERS
Not yet submitted; mail 19-May by KMP
* FORMAT-OP-C (Version 4/ 5-Jun-87)
(What does ~C do?)
Ready for release?
FUNCTION-TYPE (Version 4/ 29-May-87)
(Change definition of FUNCTIONP, function type ...)
[EB, GLS, PC] Release as is [GK] Stronger [Moon] OK after comments
addressed
[KMP] break in two, so I could
support the half I like and only grump about the parts I don't
want stronger warning
[SEF] 2-option, 3-option version
GET-SETF-METHOD-ENVIRONMENT (Version 3, 5-jun-87)
(Environment argument for GET-SETF-METHOD)
[EB, GLS, PC, Moon, SEF] Release as is
[GK] Ballot says comments follow, but no comments?
[KMP] NIL as null lexical environment
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
Submitted by Pitman 23-Apr-87
In discussion: merge with other controls for
unsolicited messages?
* IF-BODY (Version 5, 29 Apr 87)
(extend IF to implicit progn if more than one ELSE form?)
General agreement to recommend against.
While EB, PC, Moon voted to wait for a version that KMP and SEF
agreed was fair, SEF said 5 was fair enough.
Ready for release
IGNORE-ERRORS (Version 4, 29-May-87)
[EB, LMM, PC, Moon] Wait for error proposal
[GLS, KMP, SEF] Release as is (but remove "Larry wonders ...")
LMM wants KMP to submit as proposal from Error committee
IMPORT-SETF-SYMBOL-PACKAGE (Version 4/ 29-May-87)
Version 3 Released
Version 4 ready for re-release after Revision->Version
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5/5 Jun)
[EB, GLS, PC, Moon] Release as is (some typos) [SEF] Comments
MACRO-FUNCTION-ENVIRONMENT
Not yet submitted (From ENVIRONMENT-ARGUMENTS)
PATHNAME-STREAM (Version 2)
[EB, GK, PC, Moon, SEF] Release as is
PATHNAME-SYMBOL (Version 2)
[GLS, PC, Moon, KMP, SEF] Release as is [eb] against, want minority
view (needs formatting)
Moon " cover every argument that is called pathname, filename, file, or
new-name
and leave the rest of the ambiguities for another proposal?"
Not ready for release
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
Agreed to be controversial
[EB, GLS, PC, KMP] Withdraw from consideration, await new proposal
PRINC-CHARACTER (Version 3)
Mailed by KMP 29-Apr-87.
Ready for release?
PROCLAIM-LEXICAL (Version 1)
In discussion
Some progress
Need volunteer to merge comments into new version
PROMPT-FOR (Version 1)
Agreed to be controversial
[EB, PC, Moon, SEF] Withdraw
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
Not yet submitted. [PC, SEF] (PUSH FIRST SECOND)
REMF-DESTURCTION-UNSPECIFIED (Version 1)
Submitted by DLA
Discussion?
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Version 2 by KMP 28 Apr 87
In discussion, no clear consensus
[EB] Unchanged [PC, KMP, SEF] Undecided
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Mild for this proposal, but preference for
removing FONT and BITS attribute
[EB] Release as is [pc, KMP] no, remove bits & font, fuller character
proposal
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Withdraw?
SHARPSIGN-PLUS-MINUS-PACKAGE
Seems like general agreement for :KEYWORD.
Need to remove other options from proposal.
SPECIAL-FORM-SHADOW
Is it OK to shadow a special form with FLET, LABELS?
Not yet submitted
(From ENVIRONMENT-ARGUMENTS)
TAILP-NIL
Not yet submitted.
Needs volunteer to format.
Notes from Moon
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
In discussion
Need volunteer to summarize issues.
∂06-Jun-87 1412 RPG A Hole in Common Lisp
To: cl-cleanup@SAIL.STANFORD.EDU
Consider the nature of arguments to functions. In Common Lisp we have
these two notions: positional arguments and named arguments. In the first
case values are associated with variables depending on the positions of
passed arguments. In the latter case, the binding happens depending on
the names of the arguments, which are passed along with the arguments.
For example:
(defun f (x y &key a b) ...)
(f 1 2 :b 3 :a 4)
X and Y are positional, and A and B are named.
There is a second pair of notions: required arguments and optional arguments.
Does Common Lisp have all of the combinations of these notions?
| positional | named |
-------------------------------
required | yes | no |
-------------------------------
optional | yes | yes |
-------------------------------
It doesn't seem so. Keyword arguments combine named and optional.
Also there is no way to have a function with both required keyword and
truly optional positional arguments.
Suppose someone writes
(defun f (x y &optional a b &key foo bar baz ola)
(list x y a b foo bar baz ola))
and this form is evaluated:
(f <a1> <a2> <a3> <a4> <a5> <a6> <a7> <a8>)
The binding of the variables in the function definition goes like this:
x is bound to <a1>, y is bound to <a2>, a is bound to <a3>, and b is
bound to <a4>. Now we lift our heads from the sand and look at what
<a5> is. It should be one of :foo, :bar, :baz, or :ola. Now suppose
we had written:
(f 1 2 :foo 4 :bar 5 :baz 6)
Did the user intend for a to be bound to :foo, or did he intend for
a and b to not be supplied?
Here is an off the wall proposal for lambda expressions; it includes
Moon's proposal for non-keyword package symbols to be names of arguments:
(lambda ({var}*
[&optional {var | (var [initform [svar]])}*]
[&required-key {var | (name var)}*]
[&rest var]
[&key {var | (name var)} [initform [svar]])}*
[&allow-other-keys]]
[&aux {var | (var [initform])}*])
{declaration | documentation-string}*
{form}*)
where var, initform, svar are exactly as before, and name is the name of
a keyword argument, which can be a symbol in any package. Parsing an
argument list proceeds as follows:
Let nrp be the number of required positional parameters. The first nrp
supplied arguments are paired with the nrp required positional parameters.
The remaining supplied arguments are scanned left-to-right, starting with
scanning for positional optionals. If a supplied argument is EQ to one of
the required named parameters names, the scanning for positional optionals
ends and all unpaired positional optionals are defaulted according to the
lambda-list specification; then named parameter parsing begins. If a
supplied argument is not EQ to any required named parameter name, it is
paired with the next positional optional parameter.
Once the scanning for optional positional parameters has ended, scanning
for named parameters begins. Named parameter parsing is as in current
Common Lisp, except that if, at the end, there are unsupplied
required named arguments, an error is signaled.
The difference between this parsing algorithm and the current Common Lisp
one is that the occurrence of the first required named parameter stops
parsing of positional optionals. Therefore, the only way to pass the name
of required named parameter is as a required positional or required named
argument. Also, if optional named arguments appear to the left of all
required named arguments, they can be taken as positional optionals.
Examples:
(defun f (x y &optional a b &required-key foo bar &key baz ola)
(list x y a b foo bar baz ola))
(f 1 2 3 4 :foo 5 :bar 6 :baz 7 :ola 8)
=> (1 2 3 4 5 6 7 8)
(f 1 2 3 :bar 4 :baz 5 :foo 6 :ola 7)
=> (1 2 3 nil 6 4 5 7)
(f 1 2 :baz 3 :foo 4 :bar 5)
=> (1 2 :baz 3 4 5 nil nil)
(f 1 2 :baz :foo 3 :bar 4)
=> (1 2 :baz nil 3 4 nil nil)
This has the advantage that it could make some things in CLOS easier
to deal with. For example, we could define methods that discriminated
on the names of required named arguments:
(defmethod foo (x y &required-key foo bar) `(foobar ,x ,y ,foo ,bar))
(defmethod foo (x y &required-key baz ola) `(bazola ,x ,y ,foo ,bar))
(foo 1 2 :foo 3 :bar 4) => (foobar 1 2 3 4)
(foo 1 2 :baz 3 :ola 4) => (bazola 1 2 3 4)
(foo 1 2 :foo 3 :ola 4) => error
-rpg-
∂06-Jun-87 1630 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
I regard this issue as a put-up-or-shut-up affair. I prefer
the formulation that states that APPLY and FUNCALL take functions,
and you have to coerce symbols and lambda-expressions to be functions
before you can APPLY or FUNCALL them to more lenient formulations.
If we do not go with this formulation, then I would say an
important design criterion of the cleanup is:
Changes that introduce or retain inconsistencies which confuse new users
and which complicate the rules of the language are preferable to changes
that cause old programs to stop working.
I think Common Lisp is so messed up that the cleanest change to
function types will not effect major improvements. Our position
with respect to EuLisp will be more difficult.
Put up or shut up: I don't care which you choose.
-rpg-
∂06-Jun-87 1802 FAHLMAN@C.CS.CMU.EDU A Hole in Common Lisp
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jun 87 18:02:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 6 Jun 87 21:01:40-EDT
Date: Sat, 6 Jun 1987 21:01 EDT
Message-ID: <FAHLMAN.12308458446.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: A Hole in Common Lisp
In-reply-to: Msg of 6 Jun 1987 17:12-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Of course, it's too late for Common Lisp -- this would be a VERY
incompatible change for no very good reason. And, of course, you can
get the effect of a required keyword argument by signalling an error in
the init form. We could provide some conventional function for
signalling this error and CLOS could recognize this and treat that arg
as required.
Even if I were designing a new Lisp from scratch, I'm not sure that I
would want to fill in the fourth box in your matrix. By-name arguments
are for functions that have so many arguments that you can't remember
the order, or so many that it is convenient just to type in the two or
three you need and not the twenty you don't need. But if the by-name
arguments are required, you have to type them all. Furthermore, you
must remember them all (or look them up to make sure you haven't
forgotten one), and in that case you may as well enter them in the
canonical order.
Even if I wanted to mix positional and named args in a single function,
I don't like your way of doing it -- it seems treacherous to me. If the
value of certain arguments to a function happen to match the named
arguments, things get interpreted in an unintended and very mysterious
way. This would only be a good scheme if there were absolute separation
between the space of legal arguments and the space of arg names. We
would have to go back to saying that all keywords must be keywords, and
we would also have to eliminate the practice of using keywords for other
things. Or else we would have to create a new kind of object that is
reserved for use in arg names.
I have sometimes thought that if I were designing a lisp-like language
from scratch, I would leave the question of by-postion or by-name
arguments to the caller of a function. He's the one who can decide
whether he wants to remember the order of arguments or to do some extra
typing. A lambda would have the following simple form (setting aside
&rest and &more arguments for now, and flushing &aux, which was a
mistake from the start):
(lambda ({var | (var intiform) | (var initform svar) }* )
declarations, docs, body, etc. )
Variables with no initform are required. They need not be at the head
of the list.
There are two forms of function calling, postional and by-arg-name
either of which can be used on any function. They need to be
syntactically distinguished somehow. I'll use square brackets to group
the name/argument pairs in the latter -- this might be a read macro that
turns into some three-element list with a reserved token in the car.
(function-name pos-arg-1 pos-arg-2 pos-arg-3 ...)
(function-name [nameX argX] [nameY argY] ...)
The latter form says to look up the argument names at the time of the
call and rearrange the call into the order the function is expecting;
cacheing of this step is encouraged. The order of evaluation of a
function's args would be explicitly unpredictable in this language, so
the rearrangement is legal and not difficult.
Then the function gets called, unsupplied args get their initforms
evaluated, and if any of the required args does not have a value
assigned, an error is signaled. If the lambda list has any optional
args before a required arg, the only way NOT to supply a value for the
optional args is to use the by-name form of call.
One can imagine versions of this in which the caller can mix positional
and named args -- some arguments and then some bracketed pairs -- but if
this is allowed, one would have to worry about what happens if the same
variable gets a positional value and a by-name value. Signal an error,
I guess, or say that the result is indeterminate.
-- Scott
∂07-Jun-87 0826 FAHLMAN@C.CS.CMU.EDU Rules
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 08:26:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 11:26:18-EDT
Date: Sun, 7 Jun 1987 11:26 EDT
Message-ID: <FAHLMAN.12308615853.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Rules
I think that KMP is a bit out of line in complaining that he has now
blown his entire time budget for this stuff and that new versions are
somehow out of line. When problems are spotted, even late in the
process, they have to be fixed, and then we need another round of
consideration. Things only become final if we manage to come up with a
version that nobody objects to, or if we explicitly agree to disagree.
For those of us who insist upon having a say on the final form of every
issue, it is impossible to set an a priori limit on the time that will
be required. We need some balance between the power of the chairman to
ram through a lot of unexamined changes at the last minute and the power
of any one member to block progress because he has some other commitments.
However, I agree with KMP that Masinter is at fault in several areas.
The most serious problem is that he has greatly increased the amount of
time the rest of us must spend in considering new versions by changing
things in gratuitous and unrecorded ways. Larry also put a few of his
own ideas into the new versions without any prior discussion -- a
practice he used to complain bitterly about when I was chairman.
Finally, he has thrown everyone into a panic by making it look like a
modified proposal might go out with a statement of support by people who
stated support for the previous version and not necessarily the current
one.
-- Scott
∂07-Jun-87 1150 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jun 87 11:50:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 166143; Sun 7-Jun-87 14:50:04 EDT
Date: Sun, 7 Jun 87 14:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: RPG@SAIL.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 6 Jun 87 19:30 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870607144946.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 06 Jun 87 1630 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
... Changes that introduce or retain inconsistencies which confuse new
users and which complicate the rules of the language are preferable to
changes that cause old programs to stop working.
I think Common Lisp is so messed up that the cleanest change to
function types will not effect major improvements. Our position
with respect to EuLisp will be more difficult. ...
I disagree with your claim that a change to the function types alone will
not make a major improvement in the language.
We can define any function to do anything we want. That in itself does
not make the language inconsistent. There is nothing inconsistent about
defining the functions FUNCALL and APPLY to take arguments which are
coercible to functions, especially if you also make it clear that you
can put things in function cells which are coercible to functions.
This is no more unreasonable than allowing any function to coerce its
argument. Consider STRING-DOWNCASE of a symbol, for example.
One of the great powers of types in a language is that you can tell when
you have one that is not quite suitable and define an interpretation for
it. If you require exactly one type as an argument to all functions, you
alienate the whole notion of generic functions and take us into a world
that more resembles CLU, where you need one function for every type.
If all we did was fix the types and not fix the business about what can go
in the cells or be given to APPLY or FUNCALL, we'd still have a lot.
Consider that if the EuLisp guys don't like our definition of the functions
and want to run EuLisp compatibility in our lisp, they can effectively do:
(IN-PACKAGE "EULISP" :USE "CL")
(SHADOW '(APPLY FUNCALL))
...
(DEFUN APPLY (FUNCTION &REST SPREAD-ARGUMENTS)
(CL:APPLY (THE FUNCTION #'CL:APPLY)
(THE FUNCTION FUNCTION) SPREAD-ARGUMENTS))
(DEFUN FUNCALL (FUNCTION &REST ARGUMENTS)
(CL:APPLY (THE FUNCTION FN) ARGUMENTS))
And as for us, we can do the following to win in theirs:
(IN-PACKAGE "COMMONLISP" :USE "EU")
(SHADOW '(APPLY FUNCALL))
...
(PROCLAIM '(INLINE COERCE-TO-FUNCTION))
(DEFUN COERCE-TO-FUNCTION (FN)
(FLET ((FAIL () (ERROR "Not a function: ~S" FN)))
(TYPECASE FN
(FUNCTION FN)
(SYMBOL (SYMBOL-FUNCTION FN))
(LIST (IF (EQ (CAR LIST) 'LAMBDA)
(EVAL ,LIST)
(FAIL)))
(OTHERWISE (FAIL)))))
(DEFUN APPLY (FN &REST SPREAD-ARGUMENTS)
(EU:APPLY #'EU:APPLY (COERCE-TO-FUNCTION FN) SPREAD-ARGUMENTS))
(DEFUN FUNCALL (FN &REST ARGUMENTS)
(EU:APPLY (COERCE-TO-FUNCTION FN) ARGUMENTS))
Not much code for either side.
The thing which makes this so easy going both directions is the agreement
on making the FUNCTION type something that you can get leverage out
of.
The issue of how you deal with that type in any given function is
interesting, but need not (and I think should not) be intimately tied
up with this much more important issue that we probably can and should
all agree upon.
You might say that this is so little code that we should go the extra
little bit and just agree to make the mechanisms the same, but I don't
think that would be wise. To go further for us would compromise large
bodies of existing code and built-in philosophies about Lisp and what
it can do for them. To go further for the Eulisp guys might compromise
their existing code and their philosophies. I think that either side
has a defensible reason for maintaining their ground and that it is
appropriate to agree not to agree on this issue.
∂07-Jun-87 1259 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 12:52:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 15:51:42-EDT
Date: Sun, 7 Jun 1987 15:51 EDT
Message-ID: <FAHLMAN.12308664162.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 7 Jun 1987 14:49-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I think the issues involved in FUNCTION-TYPE are now clearly drawn and
we may as well settle this whole package one way or the other, rather
than separating the issue into parts, settling the type cleanup now, and
letting the related questions hang in limbo for another six months.
It's a bit frightening to me personally to propose this, since I won't
be at the Boston meeting, but I'd rather have a clear decision in favor
of ANY of the three proposals than to let this hang indefinitely.
It is reasonable to let questions hang if we're waiting for some related
issues to be resolved or if technical work needs to be done (as in
solving the macro problem for Lisp-1) or if people really need time to
study the implications of a proposed change. I don't see any of those
factors at work in the FUNCTION-TYPE issue -- it is a straightforward
question of whether we want to remove some ugly tangles from the
language at the expense of breaking some existing code. This question
is not going to get any easier, and until it is decided we all have to
code defensively.
Shall I attempt to write up FUNCTION-TYPE as a three-option proposal
that can be debated and voted on in Boston?
-- Scott
∂07-Jun-87 1318 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jun 87 13:18:22 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 166175; Sun 7-Jun-87 16:17:14 EDT
Date: Sun, 7 Jun 87 16:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308664162.BABYL@C.CS.CMU.EDU>
Message-ID: <870607161700.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I do not believe that all that can be usefully said about FUNCTION-TYPE
has been said. For example, I would like to discuss further this issue
you raised of providing a function to get the original s-expression from
a coerced function (of clean-type FUNCTION). T has such a function.
Its mere presence doesn't make everything ok, but it might contribute
to some overall theory. Before making a proposal, I need to study the
consequences of having it a bit more -- and I have no time to do that
right in the next couple of weeks. The details of this issue could
affect my view on the proposal currently on the table.
For reasons such as this, I feel that it would be premature to bring
FUNCTION-TYPE to the table at this meeting. I'd rather see this brought
to X3J13 only when we were sure we had things carefully thought out, to
preclude wasting valuable time in in-person meetings due to inadequate
preparation. The fact that Steele (and you?) will not be at the Boston
meeting is another good reason to wait.
Let's just keep this one on hold for two more months. I don't see how
that much time can hurt a lot, and I do see how it can help. It's not
like we don't have enough else to keep us all busy in the interim.
∂07-Jun-87 1348 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 13:48:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 16:47:37-EDT
Date: Sun, 7 Jun 1987 16:47 EDT
Message-ID: <FAHLMAN.12308674344.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 7 Jun 1987 16:17-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Well, I'll leave it to the others to decide whether it is reasonable to
delay the whole decision process for several months because you haven't
yet decided what your position is. If several people on the committee
are uneasy about this FUNCTION-TYPE issue because of the points you have
raised (or because of other problems), we should probably wait and
discuss it some more; if it's just you, I don't think you have a veto
either over the proposal itself or over the decision that it's time to
vote on it. (You may, however, have a legitimate parliamentary
objection if the proposal being voted on has not been on the table for a
sufficient time prior to a vote.)
It's possible that this can be discussed in Boston and settled by a
letter ballot shortly thereafter. Unlike most of these "garbage"
issues, I think this one is worth some of our precious face-to-face
time.
By the way, I thought I had told people on Cleanup this, but I guess I
just told certain individuals: I will not be able to be at the Boston
meeting. I had already made plans to be in England when this meeting's
date was settled in Palo Alto. I'd like to be at the meeting, but I
trust the members of X3J13 not to do anything too horrible in my
absence.
-- Scott
∂07-Jun-87 1603 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 16:02:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:02:22-EDT
Date: Sun, 7 Jun 1987 19:02 EDT
Message-ID: <FAHLMAN.12308698874.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FORMAT-OP-C (Version 4)
In-reply-to: Msg of 5 Jun 1987 18:04-EDT from Masinter.pa at Xerox.COM
This version is OK by me except for the last paragraph of the
discussion. I think you're introducing an entirely new topic in the
offhand comment about READ-CHAR always returning one charater for every
one WRITE-CHAR has written. This might be worth a clarification of its
own, but it shouldn't be introduced here, especially as a
"clarification", which makes it sound like that interpretation is
obvious to the people who endorse FORMAT-OP-C.
Drop the last paragraph?
-- Scott
∂07-Jun-87 1612 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 16:12:45 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:12:08-EDT
Date: Sun, 7 Jun 1987 19:12 EDT
Message-ID: <FAHLMAN.12308700652.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
In-reply-to: Msg of 5 Jun 1987 19:10-EDT from Masinter.pa at Xerox.COM
This looks good to me.
-- Scott
∂07-Jun-87 1622 RPG Hole
To: cl-cleanup@SAIL.STANFORD.EDU
Actually, I think I wrote things up so that if no one uses &required-key,
everything behaves as before. Possibly there is some definition of
``compatible'' with which I am not familiar such that this behavior is
``very incompatible?''
I suppose if someone wants to not have to remember twenty keywords, they
don't have to use &required-keys.
I ran through the exercise of inventing a new type of object for
names of arguments, but then when I considered the frequency of
this sort of checking and the ways I know type space is divided in
current implementations, it didn't seem worth it.
Of course, if CLOS needs required named arguments for discrimination
(not error signaling) it can be a feature of CLOS lambda-lists
not available in Common Lisp. The syntax of CLOS lambda-lists is an extension
already.
-rpg+
∂07-Jun-87 1630 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 16:30:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:29:54-EDT
Date: Sun, 7 Jun 1987 19:29 EDT
Message-ID: <FAHLMAN.12308703889.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
In-reply-to: Msg of 6 Jun 1987 00:48-EDT from Masinter.pa at Xerox.COM
Rather than wait for some resolution of Kent's question about the
omission of the :DISPLACED-TO argument, I took the liberty of guessing
that adjusting a displaced-to array without setting the :displaced-to
meant that the result was displaced to the same place. I inserted rule 3
and renumbered the rules.
The manual is pretty vague in this area, but my reading of
ADJUST-ARRAY (which says that the :DISPLACED-TO argument is the same as
in MAKE-ARRAY) is that if no :DISPLACED-TO argument is supplied, the
resulting array is never displaced, even if it had been originally.
That's what we implemented in Spice Lisp, and that's the interpretation
that seems to be consistent with the rest of this proposal (e.g. the rule
that if :DISPLACED-INDEX-ARG is not supplied, it defaults to zero rather
than the old index).
So I support the earlier version of the proposal, with the added
clarification that if no :DISPLACED-TO argument is supplied in a call to
ADJUST-ARRAY, the resulting array is not displaced, even if the original
array had been displaced. That is clear, simple, and sufficient in my
view.
It might be argued that a displaced array should remain displaced unless
the user specifically specifies otherwise. I can imagine some
modularity arguments for such a view, though I don't think they are
compelling. If someone strongly prefers this interpretation, I wouldn't
object and would even arrange to fix the CMU code so that we can still
say that public-domain code is available. However, this change will
surprise some people and it should be clearly stated, not hidden in a
parenthetical statement in point 3. Also, we should probably go over
the whole proposal to make it consistent with this change.
-- Scott
∂07-Jun-87 1632 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
I'm sorry I used the word ``inconsistency'' when I meant to use the phrase
``multiplicity of rules.'' To new users, an abundance of rules where one
would seem to be necessary is often viewed by such users as either an
inconsistency in design philosphy among the various parts of the language
or an inconsistency in the sanity of the designers of the language.
I rephrase my cynical design rule:
``Changes that introduce or retain a multiplicity of rules where a single
rule will do are preferable to changes that cause old programs to stop
working.''
-rpg-
∂07-Jun-87 1648 RPG FUNCTION-TYPE and EuLisp
To: cl-cleanup@SAIL.STANFORD.EDU
I said in a message:
``Our position with respect to EuLisp will be more difficult....''
KMP goes on to argue various positions the EuLisp folks might have. I
suppose a reasonable way to proceed is to set up KMP and some other people
to simulate the EuLisp folks and assume positions they might have, and we
can see how well our arguments might apply to those positions, but what I
meant by my remark is that if we moved as far as the cleanest formulation
of the FUNCTION-TYPE issue, that would be seen as an act of good faith on
our part and would cause the two groups to move much closer together and
to proceed with a common design much more easily.
If, for example, we changed Common Lisp to be a Lisp1 dialect, the groups
would merge. By ``position'' I meant negotiation position. I don't expect
this group to understand the process of negotiating with the EuLisp folks,
so there is no point in arguing the merits here.
-rpg-
∂07-Jun-87 1753 FAHLMAN@C.CS.CMU.EDU AREF-1D (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:53:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:53:13-EDT
Date: Sun, 7 Jun 1987 20:53 EDT
Message-ID: <FAHLMAN.12308719055.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: AREF-1D (Version 4)
In-reply-to: Msg of 6 Jun 1987 00:52-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1755 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:55:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:54:24-EDT
Date: Sun, 7 Jun 1987 20:54 EDT
Message-ID: <FAHLMAN.12308719270.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
In-reply-to: Msg of 6 Jun 1987 00:57-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:55:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:54:49-EDT
Date: Sun, 7 Jun 1987 20:54 EDT
Message-ID: <FAHLMAN.12308719347.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
In-reply-to: Msg of 6 Jun 1987 01:37-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: DEFVAR-INITIALIZATION (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:56:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:55:26-EDT
Date: Sun, 7 Jun 1987 20:55 EDT
Message-ID: <FAHLMAN.12308719458.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
In-reply-to: Msg of 6 Jun 1987 01:43-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂07-Jun-87 1756 FAHLMAN@C.CS.CMU.EDU Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87 17:56:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:56:00-EDT
Date: Sun, 7 Jun 1987 20:55 EDT
Message-ID: <FAHLMAN.12308719561.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
In-reply-to: Msg of 6 Jun 1987 02:27-EDT from Masinter.pa at Xerox.COM
Looks good to me.
-- Scott
∂08-Jun-87 0646 gls@Think.COM FORMAT-OP-C (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87 06:46:37 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 8 Jun 87 09:48:58 EDT
Date: Mon, 8 Jun 87 09:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: FORMAT-OP-C (Version 4)
To: Masinter.pa@xerox.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870605-150551-2556@Xerox>
Message-Id: <870608094647.1.GLS@BOETHIUS.THINK.COM>
I approve of FORMAT-OP-C:WRITE-CHAR, version 4.
Good work, Larry.
--Guy
∂08-Jun-87 0727 gls@Think.COM Hole
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87 07:27:00 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 8 Jun 87 10:29:36 EDT
Date: Mon, 8 Jun 87 10:27 EDT
From: Guy Steele <gls@Think.COM>
Subject: Hole
To: RPG@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <8706072326.AA12046@Think.COM>
Message-Id: <870608102731.4.GLS@BOETHIUS.THINK.COM>
It strikes me that the interaction of &optional and &required-key
arguments is dicey at best. It might be better to allow one or the
other kind of argument but not both in a single lambda-list.
I am also not crazy about the name &required-key; it is too obviously
the result of leaning over backwards to accommodate history.
An aesthetically more pleasing design that deals with both objections
is simply to use the existing keywords &key and &optional, with the
extension that &optional may occur *after* &key if desired. That is, it
is still true that each of &optional and &key may appear at most once in
an argument list, but they may appear in either order. Thus &key marks
the transition from by-position to by-name, and &optional marks the
transition from required to optional. One may then have either of two
patterns:
(defun blah (x y z &optional p q r &key a b c) ...)
----- ----- -----
| | |
| | optional named
| optional positional
required positional
(defun blee (x y z &key p q r &optional a b c) ...)
----- ----- -----
| | |
| | optional named
| required named
required positional
Thus required named and optional positional cannot be mixed,
and no new keyword is needed. The only unfortunate aspect of
this proposal is that it is incompatible with previous practice.
Currently
(defun blaw (x y z &key a b c) ...)
treats a, b, and c as optioal named parameters, whereas this
new proposal would treat them as required.
--Guy
∂08-Jun-87 0802 FAHLMAN@C.CS.CMU.EDU Hole
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 08:01:57 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 11:00:42-EDT
Date: Mon, 8 Jun 1987 11:00 EDT
Message-ID: <FAHLMAN.12308873322.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Hole
In-reply-to: Msg of 8 Jun 1987 10:27-EDT from Guy Steele <gls at Think.COM>
Well, I was wrong about this being incomaptible, but I still don't see
what problem you two think you are solving, unless an empty box in the
matrix of possible language constructs is considered to be a problem.
Does this make life any better for the user of Common Lisp?
-- Scott
∂08-Jun-87 1128 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87 11:28:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 87 11:25:16 PDT
Date: 8 Jun 87 11:21 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LOAD-TIME-EVAL (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
Message-ID: <870608-112516-4180@Xerox>
This issue was just submitted by Jim Kempf. I made some minor edits to
his submission (e.g. fundef => function definition) but it is otherwise
as submitted.
My comments:
I think the test case needs to be fixed up so that it can stand alone
(i.e., be a fragment of code that could, for example, become a part of a
diagnostic suite).
Does this have any justification other than the Common Lisp Object
System? (I think it does, but they aren't mentioned here.)
Other than that, I think it looks OK. What do you think?
!
Issue: SHARP-COMMA-SPECIAL-FORM
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: Version 1 submitted 6/6/87, James Kempf.
Problem description:
The specification of #, (load time evaluation) in Common Lisp does not
provide a means of generating code using macros which can perform load
time evaluation within embedded forms. Load time evaluation at the top
level is possible using (EVAL-WHEN (LOAD) ... ), but there is no way
arrange for a form generated by a macro to be evaluated at load time
because #, is a reader macro and code generated by macros is not
processed by the reader.
Proposal (SHARP-COMMA-SPECIAL-FORM:LOAD-TIME-EVAL):
When interpreted or compiled in memory, LOAD-TIME-EVAL evaluates its
argument immediately. When being compiled as part of a file compilation,
LOAD-TIME-EVAL arranges for its argument to be evaluated when the file
is loaded. LOAD-TIME-EVAL can be used anywhere, and is not restricted to
being a top level form, nor to code being processed by the reader.
Test Case:
(defmacro call-method (spec &rest args)
`(apply
(load-time-eval
(load-time-look-up-method ,spec))
,args)))
This macro generates code which applies a function which is determined
at load time. It is a summary of some more complex code in the
CommonObjects object-oriented language extension built on the Common
Lisp Object System.
Rationale:
Currently, there is no way to arrange for load time evaluation within
macro generated code. This capability is required for object-oriented
extensions of Common Lisp, since often neither the name nor the function
definition object is known until load time. It is particularly useful
for optimizing calls to superclass methods.
Current practice:
Currently, every version of Common Lisp is required to implement
compiler hooks for #, so the primitives for implementing LOAD-TIME-EVAL
should exist.
Adoption Cost:
The cost to implementors should be relatively slight, considering
primitives for implementing #, can be resued. Many implementations of
Common Lisp may have LOAD-TIME-EVAL available as public domain code, if
they done it for Portable Common Loops.
Cost of non-adoption:
Optimization of CALL-NEXT-METHOD in the Common Lisp Object System will
be implementation dependent, and other languages built on the metaclass
kernel wanting to optimize calls to superclass methods will have no
specified, portable way of doing so.
Benefits:
Optimization of calls on superclass methods in the Common Lisp Object
System will have a portable hook, which will make transporting code
easier. If the problem is left as it is, each vendor could solve the
problem differently, encouraging nonportable code.
Conversion Cost:
Extremely low. Most users will be completely unaffected.
Esthetics:
The proposal fills a hole in the spectrum of alternatives for achieving
load time evaluation. Currently, code which is read by the reader can
arrange for it to be done, as can top level code, but embedded code
cannot.
Discussion:
There seems to be little disagreement on this, as far as can be
determined at this date. The Portable Common Loops implementation
encourages vendors to add this, to facilitate calling superclass methods
directly, and there has not been any negative reaction so far. It will
certainly help make the Common Lisp Object System easier to implement,
and easier to extend.
∂08-Jun-87 1240 RPG Hole
To: cl-cleanup@SAIL.STANFORD.EDU
The only problem that could be solved by filling in this hole is to
give people a way to supply fewer than all of the optional positionals
while supplying some of the named arguments. My suggestion doesn't help
with that much.
As I've mentioned before - but as I know I must mention again - the effect
of this might have some relevance to CLOS in which it might be useful (the
CLOS folks have not yet decided) to discriminate on the names of named
arguments.
For example, writing this
(defmethod f ((x c1) (y c2) &required-key foo bar) <code1>)
(defmethod f ((x c1) (y c2) &required-key baz ola) <code2>)
is simpler to understand than this
(defmethod f ((x c1) (y c2)
&key (foo nil foo-p) (bar nil bar-p)
(baz nil baz-p) (ola nil ola-p))
(cond ((and foo-p bar-p) <code1>)
((and baz-p ola-p) <code2>)))
And when one writes instance initialization code in CLOS, you will be
writing lots of code like this.
-rpg-
∂08-Jun-87 1342 FAHLMAN@C.CS.CMU.EDU Hole
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 13:42:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 16:41:08-EDT
Date: Mon, 8 Jun 1987 16:40 EDT
Message-ID: <FAHLMAN.12308935290.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Hole
In-reply-to: Msg of 8 Jun 1987 15:40-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
The only problem that could be solved by filling in this hole is to
give people a way to supply fewer than all of the optional positionals
while supplying some of the named arguments. My suggestion doesn't help
with that much.
As I've mentioned before - but as I know I must mention again - the effect
of this might have some relevance to CLOS in which it might be useful (the
CLOS folks have not yet decided) to discriminate on the names of named
arguments.
Maybe this suggests that it is time to bite the bullet and let CLOS
methods discriminate on non-required args, keyword or otherwise. The
last time I heard this discussed, it was more a matter of "we don't want
to think about how to extend the priority rules right now" than "we
can't discriminate on optional args for the following fundamental
reason". Has that changed?
-- Scott
∂08-Jun-87 2001 FAHLMAN@C.CS.CMU.EDU Issue: LOAD-TIME-EVAL (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 20:01:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 23:00:16-EDT
Date: Mon, 8 Jun 1987 23:00 EDT
Message-ID: <FAHLMAN.12309004326.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabsc@HPLABS.HP.COM
Subject: Issue: LOAD-TIME-EVAL (Version 1)
In-reply-to: Msg of 8 Jun 1987 14:21-EDT from Masinter.pa at Xerox.COM
This looks like a good proposal in general, and it is something I would
like to see adopted. I think that this facility will be used for lots
of things besides CLOS metaclass hackery, and that a less arcane
justification would look better. I seem to recall people asking for
this long before CommonLoops or CLOS appered on the scene.
I'll see if I can come up with some straightforward and self-contained
example that needs this facility. The rest of you should do likewise.
If nobody can do better in the next day or two, I think that this
proposal could go out as is -- I don't think anyone will oppose it, even
if it is presented as an arcane hack needed only by CLOS wizards.
-- Scott
∂08-Jun-87 2126 KMP@STONY-BROOK.SCRC.Symbolics.COM LOAD-TIME-EVAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Jun 87 21:26:11 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 167692; Mon 8-Jun-87 23:37:14 EDT
Date: Mon, 8 Jun 87 23:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: LOAD-TIME-EVAL
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12309004326.BABYL@C.CS.CMU.EDU>
Message-ID: <870608233713.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
In Maclisp, the SQUID (Self-Quoting Internal Datum) feature in the compiler
offered this same advantage. It was very useful in my Fortran->Lisp translator,
which needed to do the conceptual analog of relocation at load time. I had
one big array called FORTRAN$MEMORY and programs didn't know until load time
what their private data area's offset in that array would be.
I've run into other examples, too, but maybe this suffices to convince people
that CLOS is not the only potential consumer.
Anyway, I'm conceptually in favor of having this capability though I've not
had time to read the particular proposal in detail yet.
∂09-Jun-87 1732 Masinter.pa@Xerox.COM procedural, errors.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 17:32:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 17:32:08 PDT
Date: 9 Jun 87 17:31 PDT
From: Masinter.pa@Xerox.COM
Subject: procedural, errors.
To: FAHLMAN@C.CS.CMU.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870609-173208-1834@Xerox>
I spoke with Kent on the telephone yesterday. Briefly:
Kent will present ignore-errors. He can chose whether he wants to report
it out of the cleanup committee, the error committee, or both, but it
will be go out "under separate cover" so that it is at least apparent
that the error committee approves it.
It turns out that I didn't in fact make any unannounced edits to any
proposals. The wording that upset Kent was the inclusion of the phrase
"including NIL" in KEYWORD-ARGUMENT-NAME-PACKAGE, but the wording was
there (exactly) in the version that got voted on. However, when I fixed
up the line breaks, Kent's source compare didn't work.
So perhaps there weren't any gratuitous and unrecorded changes, although
I admit there were a flurry of hurried ones. In any case, your concerns
have been noted, and I will redouble efforts to avoid any in the future.
I would like to start pipelining proposals out to X3J13, starting with
the ones that have had no discussion for quite a while. The messages to
X3J13 will be careful to say whether the committee voted on the exact
version or some previous one; if there's any doubt, I'll double check
with this mailing list first.
I expect that mail to X3J13 may generate some discussion, questions,
etc. We may want to be prepared to make slight revisions.
∂09-Jun-87 1822 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:21:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 18:21:23 PDT
Date: 9 Jun 87 18:21 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
To: cl-cleanup@sail.stanford.edu
Message-ID: <870609-182123-1906@Xerox>
Will Clinger mentioned to me at the last X3J13 one important reason for
the stronger interpretation which I hadn't thought of. The issue is
garbage collection of unused functions. The idea is to gc all functions
in the system which aren't called, at the point of building an
application. However, when funcall and friends can automatically coerce
symbols, then any funcall potentially becomes a reference to any
symbol-named function in the environment (without some really hairy and
impossible flow analysis.) If there is no automatic coercion, and there
aren't any explicit symbol-functions, then you can be guaranteed that if
you don't see a call to FOO or a #'FOO somewhere, then FOO isn't
referenced and its definition can be GC'd.
∂09-Jun-87 1835 KMP@STONY-BROOK.SCRC.Symbolics.COM procedural, errors.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:35:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168880; Tue 9-Jun-87 21:34:53 EDT
Date: Tue, 9 Jun 87 21:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: procedural, errors.
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.PA@Xerox.COM, Fahlman@C.CS.CMU.EDU,
KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870609-173208-1834@Xerox>
Message-ID: <870609213452.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Larry's message accurately sums up the situation, I think.
I gather that some people worried I might be hopelessly irritated at
Larry, so I should say that I'm not. I was just concerned about a bad
situation which might recur and felt I should say something to keep
things in check. Had it not been so late, perhaps I'd have edited my
comments better.
Larry seems committed to making the documents accurately reflect whether
in fact we've seen or voted on or agreed upon a particular draft, and
that's what's important to this situation.
∂09-Jun-87 1838 Pavel.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 18:36:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 18:36:09 PDT
Date: Tue, 9 Jun 87 18:36:04 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
In-reply-to: <870609-182123-1906@Xerox>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Message-ID: <870609-183609-1934@Xerox>
Date: 9 Jun 87 18:21 PDT
From: Masinter.pa
If there is no automatic coercion, and there
aren't any explicit symbol-functions, then you can be guaranteed that
if
you don't see a call to FOO or a #'FOO somewhere, then FOO isn't
referenced and its definition can be GC'd.
One can always use manual coercion, via EVAL, so you'll also have to
outlaw any calls to thatt function in the application. It starts
seeming like this isn't such a compelling argument.
Pavel
∂09-Jun-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: LOAD-TIME-EVAL (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 20:14:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168944; Tue 9-Jun-87 23:14:13 EDT
Date: Tue, 9 Jun 87 23:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
In-Reply-To: <870608-112516-4180@Xerox>
Message-ID: <870609231403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 8 Jun 87 11:21 PDT
From: Masinter.pa@Xerox.COM
Proposal (SHARP-COMMA-SPECIAL-FORM:LOAD-TIME-EVAL)
I'm generally in favor of something like this proposal, but there are
several problems with the details.
LOAD-TIME-EVAL is presented as if it did the same thing as sharp-comma,
but they are rather different. #, must appear inside a quoted constant,
at least in any compiler implementation I am familiar with, whereas
load-time-eval is a form and must not appear inside a quoted constant.
This is not a fundamental problem, it's just confusing.
The remark "Load time evaluation at the top level is possible using
(EVAL-WHEN (LOAD) ... )" does not make any sense, as what that EVAL-WHEN
special form actually does is to inhibit evaluation when loading a file
into the interpreter; it does not cause something to be evaluated at a
different time. I think the real lesson to be learned from this little
slip is that "load time evaluation" is a poor way of describing the
feature we are trying to get at here; the feature we really want is
load-time construction of constants.
It's not crystal clear how many times LOAD-TIME-EVAL evaluates its
subform and what is done with the result. I believe the intention is
that `(foo (load-time-eval (bar))) is roughly like
`(foo (quote ,(bar))), which explains what is done with the result.
I'm not happy with the way I just explained it, but can't think of a
better way. Can the subform be evaluated more than once in interpreted
code?
There are also four typographical errors in the example, or else I am
even more confused by the way it was explained than I thought.
(defmacro call-method (spec &rest args)
`(apply
(load-time-eval
(load-time-look-up-method ,spec))
,args)))
should be
(defmacro call-method (spec &rest args)
`(funcall (load-time-eval
(load-time-look-up-method ',spec))
,@args))
It might be worth discussing the obvious other way of doing this, which
would be a function called by a macro, instead of a special form
included in the expansion of a macro. I think this would have a closer
analogy to #,; in fact you just write , in your macro's backquote where
you would have written #, when using the reader macro. The above
example would be written as follows:
(defmacro call-method (spec &rest args &environment env)
`(funcall (quote ,(make-load-time-eval
`(load-time-look-up-method ',spec)
env))
,@args))
This is more verbose than the special-form way, but it may be clearer
what's going on, since there aren't any special forms. The environment
is passed to make-load-time-eval because I don't see how else it is
supposed to know whether the form resulting from the macro expansion is
going to be compiled into a file or evaluated right away. I'm not sure
we really want to adopt the make-load-time-eval approach, but I think
it may be worth discussing.
I also happen not to believe the stated usefulness of this for object
oriented programming, but that's irrelevant except that I might want to
suggest removing that from the proposal. Certainly we all know that this
type of feature is highly useful.
In conclusion, I support the general idea but cannot support the particular
wording of the current version of the proposal. When I started writing
this message, I was going to include a complete revision of the proposal,
but I have run out of energy.
∂09-Jun-87 2029 Moon@STONY-BROOK.SCRC.Symbolics.COM Hole
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 20:29:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168954; Tue 9-Jun-87 23:28:33 EDT
Date: Tue, 9 Jun 87 23:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Hole
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Dick Gabriel <RPG@SAIL.STANFORD.EDU>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308935290.BABYL@C.CS.CMU.EDU>
Message-ID: <870609232830.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 8 Jun 1987 16:40 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Maybe this suggests that it is time to bite the bullet and let CLOS
methods discriminate on non-required args, keyword or otherwise. The
last time I heard this discussed, it was more a matter of "we don't want
to think about how to extend the priority rules right now" than "we
can't discriminate on optional args for the following fundamental
reason". Has that changed?
If I remember (I haven't consulted the archives), it wasn't a case of
"we don't want to think about it". I think we came up with nine
different equally plausible extensions to provide for that case, and
couldn't find any compelling reason to choose one over the others. I
think it would be better for the CLOS committee to concentrate on
finishing what we have tackled so far, and avoid piling on even more
ambitions. These things can be added later.
∂09-Jun-87 2113 Moon@STONY-BROOK.SCRC.Symbolics.COM A Hole in Common Lisp
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87 21:12:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168977; Wed 10-Jun-87 00:11:34 EDT
Date: Wed, 10 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A Hole in Common Lisp
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308458446.BABYL@C.CS.CMU.EDU>
Message-ID: <870610001126.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 6 Jun 1987 21:01 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Even if I wanted to mix positional and named args in a single function,
I don't like your way of doing it -- it seems treacherous to me. If the
value of certain arguments to a function happen to match the named
arguments, things get interpreted in an unintended and very mysterious
way.
Exactly. If an argument can sometimes be a value for a parameter, and
other times be the name of a parameter, it can be very confusing.
Haven't we seen this same suggestion before and rejected it for that
reason? I can't remember whether "we" was the Common Lisp committee a
few years ago or a bunch of hackers sitting around at MIT a few years
before that. Anyway, my preference is to tread very cautiously on this.
I have sometimes thought that if I were designing a lisp-like language
from scratch, I would leave the question of by-postion or by-name
arguments to the caller of a function....
There [would be] two forms of function calling, positional and by-arg-name
either of which can be used on any function. They need to be
syntactically distinguished somehow. I'll use square brackets to group
the name/argument pairs in the latter -- this might be a read macro that
turns into some three-element list with a reserved token in the car.
(function-name pos-arg-1 pos-arg-2 pos-arg-3 ...)
(function-name [nameX argX] [nameY argY] ...)
This is very like the way Ada does it. If we were redesigning Lisp, my
preference would be to do it this way too. However, I'm sure we'd have
people screaming that we were destroying Lisp by introducing new syntax
and by eliminating the ability to understand keyword arguments in terms
of getf and &rest. Maybe instead of fixing Lisp to be more like Ada, I
ought to be thinking of fixing Ada to be more like Lisp.
∂09-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87 23:36:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 23:35:24 PDT
Date: 9 Jun 87 23:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 9 Jun 87 23:14 EDT
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
Message-ID: <870609-233524-2207@Xerox>
David, I agree with most of your sentiments and encourage you to attempt
a revision. The issue currently has two names, neither of which are
particularly appropriate. One is LOAD-TIME-EVAL, and the other is
SHARP-COMMA-SPECIAL-FORM. Jim's message called it LOAD-TIME-EVAL. I
changed the proposal name to SHARP-COMMA-SPECIAL-FORM in the theory that
the *issue* was some programmatic way of getting at what sharp-comma did
(even if it isn't the same).
#, is one of the stickier bits of Common Lisp, since, like compiler-let
and a few others, it opens a distinction between compiled and
interpreted code that is otherwise outside the execution model. For that
reason, this seems like an issue we might have some difficulty with.
- - - - - - - - - - - - - - -
For general interest, I'll pass along the following: Interlisp has
something like this, in constant, deferredconstant and loadtimeconstant.
(constant x) can be implemented by
(defmacro constant (x) `',(eval x)).
E.g., (constant (char-code #\Space)). Some uses were for those places
where the compiler didn't know enough to do constant folding.
Occasionally it was used for things like (constant (get-date-string))
which would return the date the form was compiled, if at all. Of course,
the interpreted behavior is possibly erratic depending on the mechanism
for macro-expansion caching.
(loadtimeconstant x)
This is similar to constant, but the compiler recognized it specially,
and emitted a special coding so that the loader would evaluate x at load
time. Since it requires special processing by the loader to detect
(e.g., a special case in the fasl format) it is a "special form". I'm
not sure how one could implement this using only a function like
make-load-time-eval. (loadtimeconstant (get-date-string)) would return
the date the compiled code was loaded. Interpreted behavior is similar
to constant, i.e., evaluation time is not specified.
(deferredconstant x)
This gets evaluated on first reference. It can be implemented by
self-modifying code, e.g.,
(defmacro deferred-constant (x)
(let ((var (gentemp)))
(proclaim (list 'special var))
`(if (boundp ',var) ,var (setq ,var ,x))))
In Interlisp implementations that didn't provide load-time-constant, it
was permissible to emulate it using deferred-constant.
∂10-Jun-87 1212 Pavel.pa@Xerox.COM Issue: FORMAT-COMMA-INTERVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 12:12:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 87 12:09:45 PDT
Date: Wed, 10 Jun 87 12:09:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Issue: FORMAT-COMMA-INTERVAL
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <870610-120945-2854@Xerox>
Issue: FORMAT-COMMA-INTERVAL
References: FORMAT integer printing (p. 388-9)
Category: ADDITION
Edit history: Version 1, Pavel, June 10, 1987
Problem description: There are times when users would like to print out
numbers with some punctuation between groups of digits. The "commachar"
argument to the ~D, ~B, ~O, ~X, and ~R FORMAT directives was introduced
to fill that need. Unfortunately, the interval at which the commachar
should be printed is always every three digits. This constraint is
annoying when a different interval would be more appropriate.
Proposal (FORMAT-COMMA-INTERVAL:YES): Add a fourth argument to the ~D,
~B, ~X, and ~O FORMAT directives, and a fifth argument to the ~R
directive, to be called the "comma-interval". This value must be an
integer and defaults to 3. When the : modifier is given to any of these
directives, the "commachar" is printed between groups of
"comma-interval" digits.
Test Cases: Under the proposal, the following forms return the indicated
values:
(format nil "~,,' ,4:B" 13) => "1101"
(format nil "~,,' ,4:B" 17) => "1 0001"
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
(format nil "~3,,,' ,2:R" 17) => "1 22"
(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"
Rationale: The current specification of FORMAT gives the user control
over almost all of the facets of printing integers. Only the wired-in
constant for the comma-interval remains, even though there are uses for
varying that number. For example, in many contexts, it would be
convenient to be able to print out numbers in binary with a space
between each group of four bits. FORMAT does not currently allow
specification of the commachar printing interval so users needing this
functionality must write it themselves, duplicating much of the logic in
every implementation's integer printing code. Other uses, requiring
other intervals, can be imagined. For example, using a "commachar" of
#\Newline and a "comma-interval" of, say, 72, very large bignums could
be printed in such a way as to ensure line-breaks at appropriate places.
Current practice: No released implementations currently support this
feature.
Adoption Cost: The change in the implementation of FORMAT is reasonably
minor and, in most cases, highly localized. Usually, the change is as
simple as taking an extra parameter and using it instead of a wired-in
value of 3.
Cost of non-adoption: Users desiring this functionality will have to
write it themselves, duplicating much of the logic involved in printing
integers at all.
Benefits: The last inflexibility in integer printing is eliminated with
a net increase in user-visible functionality.
Conversion Cost: Since the proposal involves the addition of an argument
to certain directives, the change would be entirely upward-compatible.
No user code would need to be converted.
Esthetics: By parameterizing the final piece of wired-in behavior from
integer printing, this small part of the workings of FORMAT would be
perceived as having been cleaned up.
Discussion: Pavel supports this proposal.
∂10-Jun-87 1357 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Issue: FORMAT-COMMA-INTERVAL
Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 13:57:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 183720; Wed 10-Jun-87 16:39:46 EDT
Date: Wed, 10 Jun 87 16:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COMMA-INTERVAL
To: CL-Cleanup@SAIL.Stanford.Edu
In-Reply-To: <870610-120945-2854@Xerox>
Message-ID: <870610163929.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This proposal sounds good to me.
∂10-Jun-87 1650 FAHLMAN@C.CS.CMU.EDU Issue: FORMAT-COMMA-INTERVAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 16:49:51 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 10 Jun 87 19:49:05-EDT
Date: Wed, 10 Jun 1987 19:49 EDT
Message-ID: <FAHLMAN.12309493814.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: Msg of 10 Jun 1987 15:09-EDT from Pavel.pa at Xerox.COM
Looks good to me too.
One could quibble about the repeated claim that this is "the last"
inflexibility wired into number printing. I think this is an
overstatement, but not worth a revision, since it is not an important
part of the justification.
-- Scott
∂10-Jun-87 1906 Pavel.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 19:06:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 87 18:03:54 PDT
Date: Wed, 10 Jun 87 18:03:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: <FAHLMAN.12309493814.BABYL@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870610-180354-1245@Xerox>
Date: Wed, 10 Jun 87 19:49 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
One could quibble about the repeated claim that this is "the last"
inflexibility wired into number printing. I think this is an
overstatement, but not worth a revision, since it is not an important
part of the justification.
Yeah, I felt a little funny about putting it in there, but I guess my
theatric side got the better of me. I agree that it's not really worth
a revision.
Pavel
∂10-Jun-87 2127 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:27:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169942; Wed 10-Jun-87 22:40:50 EDT
Date: Wed, 10 Jun 87 22:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308703889.BABYL@C.CS.CMU.EDU>
Message-ID: <870610224048.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 7 Jun 1987 19:29 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Rather than wait for some resolution of Kent's question about the
omission of the :DISPLACED-TO argument, I took the liberty of guessing
that adjusting a displaced-to array without setting the :displaced-to
meant that the result was displaced to the same place. I inserted rule 3
and renumbered the rules.
The manual is pretty vague in this area, but my reading of
ADJUST-ARRAY (which says that the :DISPLACED-TO argument is the same as
in MAKE-ARRAY) is that if no :DISPLACED-TO argument is supplied, the
resulting array is never displaced, even if it had been originally.
That's what we implemented in Spice Lisp, and that's the interpretation
that seems to be consistent with the rest of this proposal (e.g. the rule
that if :DISPLACED-INDEX-ARG is not supplied, it defaults to zero rather
than the old index).
Scott, I think you're right. Also I think the second paragraph on p.298
can only be interpreted as saying that if you don't specify :DISPLACED-TO,
it doesn't retain the old displacement.
So I support the earlier version of the proposal, with the added
clarification that if no :DISPLACED-TO argument is supplied in a call to
ADJUST-ARRAY, the resulting array is not displaced, even if the original
array had been displaced. That is clear, simple, and sufficient in my
view.
Agreed.
∂10-Jun-87 2129 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:29:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169946; Wed 10-Jun-87 22:54:29 EDT
Date: Wed, 10 Jun 87 22:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 6 Jun 87 19:30 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870610225426.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 06 Jun 87 1630 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
I regard this issue as a put-up-or-shut-up affair. I prefer
the formulation that states that APPLY and FUNCALL take functions,
and you have to coerce symbols and lambda-expressions to be functions
before you can APPLY or FUNCALL them to more lenient formulations.
If we do not go with this formulation, then I would say an
important design criterion of the cleanup is:
[updated version of the following quote from a later message substituted
for the original]
``Changes that introduce or retain a multiplicity of rules where a single
rule will do are preferable to changes that cause old programs to stop
working.''
Perhaps I should just keep my mouth shut, but I think that quite a
plausible case can be made that requiring an explicit coercion before
calling APPLY or FUNCALL would be introducing an extra rule and would be
more confusing to new users than permitting the coercion. I don't think
there is one "right" position on this issue, I think it is a matter of
taste and style. I don't think incompatibility with existing programs
is the primary point of resistance on this issue.
I'd really prefer that this matter of taste not hold up agreement on the
important FUNCTION-TYPE proposal. Can we separate out the coercion of
symbols and lambda expressions by function calling into a separate issue?
Dick, I don't know what you meant by "put-up-or-shut-up"; would treating
this as two separate issues be somehow unacceptable to you?
∂10-Jun-87 2130 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:30:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169947; Wed 10-Jun-87 22:59:21 EDT
Date: Wed, 10 Jun 87 22:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870605-232848-2962@Xerox>
Message-ID: <870610225918.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The adoption cost sentence about some implementations (Symbolics)
already using an optional argument to GET-SETF-METHOD for
something else seems to have disappeared in the latest revision.
I don't care a whole lot, but I don't think we want to cover up
any known adoption costs in proposals.
∂10-Jun-87 2131 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 21:31:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169951; Wed 10-Jun-87 23:09:08 EDT
Date: Wed, 10 Jun 87 23:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12307710848.BABYL@C.CS.CMU.EDU>
Message-ID: <870610230906.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 4 Jun 1987 00:34 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I support this proposal and have no problem with releasing it as-is,
except for the form in which Moon's comments are included at the end.
As it stands, this is one of those proposals that seems to say, "Let's
do A, but then again we might want to do B."
Unless Moon wants to push the alternative he raises, we should either
drop this comment or say something like the following:
"Moon pointed out that the Symbolics system currently does ..., and that
this is an equally viable alternative. However, the committee has
decided to stick with the proposal as described above."
If Moon strongly favors the alternative he describes, I could support
that as well. I just think we need to pick one or the other.
I don't strongly favor it. I'm sure it was a case of our implementors doing
the best they could to slash their way through the ambiguities of the Common
Lisp book. The way Larry dealt with this in version 3 of the proposal is
fine with me. Note, however, that I cannot support version 3 of the proposal
because of the bug that was introduced in that version (discussed in
separate mail).
∂10-Jun-87 2325 RPG Put Up or Shut Up
To: cl-cleanup@SAIL.STANFORD.EDU
I think a user has to put a multiplicity of rules in his mind when he
reads that FUNCALL calls the function..., when it really invokes the
function or coerces a symbol or a list with a LAMBDA CAR (though that
might fail) to a function and calls that. But a user has fewer rules in
mind when he knows that FUNCALL invokes the function and that there is a
standard way to coerce (COERCE).
What I mean by ``put up or shut up'' is very innocent: This is an issue in
which we either choose to make a true cleanup for aesthetic and political
reasons or we choose not to. If we choose the former, I feel we have
ammunition to use to gain a compromise with EuLisp and Scheme - this would
be fine with me. If we choose the latter, I feel we have to keep Common
Lisp away from being a Lisp (unmodified name) standard, and we must make
sure that ISO Lisp is really ISO EuLisp or some such - this would be fine
with me. Y'all get to put up or shut up, and I get to observe the outcome
and begin to act accordingly, assuming someone wishes me to act at all.
From my own standpoint, I prefer the cleaner formulation, but I am
perfectly happy with the one currently stated in the FUNCTION-TYPE
writeup; if either makes it to the floor of X3J13, I will vote for it.
I am happy to treat the important, undisputed part of the FUNCTION-TYPE
proposal as separate from the only-aesthetic, disputed part of the proposal.
-rpg-
∂11-Jun-87 0958 kempf%hplabsc@hplabs.HP.COM Re: Issue: LOAD-TIME-EVAL (Version 1)
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 09:57:17 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 11 Jun 87 09:57:00 pdt
Received: by hplabsc ; Thu, 11 Jun 87 09:55:53 pdt
Date: Thu, 11 Jun 87 09:55:53 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8706111655.AA00196@hplabsc>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: LOAD-TIME-EVAL (Version 1)
Cc: kempf%hplabsc@hplabs.HP.COM
Well, let's see if I can speak to Dave's concerns about the
proposal.
>LOAD-TIME-EVAL is presented as if it did the same thing as sharp-comma,
>but they are rather different. #, must appear inside a quoted constant,
>at least in any compiler implementation I am familiar with, whereas
>load-time-eval is a form and must not appear inside a quoted constant.
>This is not a fundamental problem, it's just confusing.
The specification for the semantics of #, is found on pg. 356 of CLtL:
#,FOO is read as the object resulting from the evaluation
of the LISP object represented by FOO, which may be the
printed representation of any LISP object. The
evaluation is done during the READ process, unless the
compiler is doing the reading, in which case it is
arranged that FOO will be evauated when the file
of compiled code is loaded. The #, syntax performs
*load-time evaluation* (italics mine) of FOO. By
contrast, #. (see above) performs a read-time
evaluation. In a sense, #, is like specifying
(EVAL LOAD) to EVAL-WHEN, whereas #. is more like
specifying (EVAL COMPILE). It makes no difference
when loading interpreted code; when code is to be
compiled, however, #. specifies compile-time
evaluation and #, specifies load time evaluation.
Since this description says nothing about having #, be inside quoted
code for the compiler, I guess I don't quite understand the confusion,
or, perhaps, am confused myself about how this fits with the model of #,.
I would agree, however, with the statement that LOAD-TIME-EVAL and
#, are different in that LOAD-TIME-EVAL is a form.
>The remark "Load time evaluation at the top level is possible using
>(EVAL-WHEN (LOAD) ... )" does not make any sense, as what that EVAL-WHEN
>special form actually does is to inhibit evaluation when loading a file
>into the interpreter; it does not cause something to be evaluated at a
>different time. I think the real lesson to be learned from this little
>slip is that "load time evaluation" is a poor way of describing the
>feature we are trying to get at here; the feature we really want is
>load-time construction of constants.
I agree that a better description of the feature may be load-time
construction of constants; however, in phrasing the proposal, I
was trying to be consistent with CLtL's description of (EVAL-WHEN (LOAD) ...)
specifically (CLtL, pg. 69):
LOAD specifies that the compiler should arrange to evaluate
the forms in the body when the compiled file containing the
EVAL-WHEN form is loaded.
The rest of this section describes Common Lisp's processing model,
into which I was trying to fit this addition.
>It's not crystal clear how many times LOAD-TIME-EVAL evaluates its
>subform and what is done with the result. I believe the intention is
>that `(foo (load-time-eval (bar))) is roughly like
>`(foo (quote ,(bar))), which explains what is done with the result.
>I'm not happy with the way I just explained it, but can't think of a
>better way. Can the subform be evaluated more than once in interpreted
>code?
The subform should be evaluated once and only once (i.e. never
not evaluated and never evaluated more than once) in interpreted
code.
>It might be worth discussing the obvious other way of doing this, which
>would be a function called by a macro, instead of a special form
>included in the expansion of a macro. I think this would have a closer
>analogy to #,; in fact you just write , in your macro's backquote where
>you would have written #, when using the reader macro. The above
>example would be written as follows:
>
> (defmacro call-method (spec &rest args &environment env)
> `(funcall (quote ,(make-load-time-eval
> `(load-time-look-up-method ',spec)
> env))
> ,@args))
>
>This is more verbose than the special-form way, but it may be clearer
>what's going on, since there aren't any special forms. The environment
>is passed to make-load-time-eval because I don't see how else it is
>supposed to know whether the form resulting from the macro expansion is
>going to be compiled into a file or evaluated right away. I'm not sure
>we really want to adopt the make-load-time-eval approach, but I think
>it may be worth discussing.
This would also be acceptable, though, as Dave noted, MAKE-LOAD-TIME-EVAL
would require some way of determining whether the form resulting from
the macro expansion will be compiled or evaluated right away. Since
environments are underspecified in CLtL, this information might not
be obtainable from the environment (though it probably would from special
variables or flags associated with the compiler, in an implementation
dependent way).
>I also happen not to believe the stated usefulness of this for object
>oriented programming, but that's irrelevant except that I might want to
>suggest removing that from the proposal. Certainly we all know that this
>type of feature is highly useful.
The usefulness comes primarily in constructing optimizations removing
method lookup. There are a number of areas where this might be handy,
including direct invocation of less specific methods, declaration of
identifer names and generic function names so particular methods
rather than their generic functions are invoked, etc. To an extent,
these can be viewed as implementation and machine specific (conventional
architecture implementations would probably benefit more), or, more
precisely, implementation and machine optional. However, as pointed
out, the type of feature which the proposal was trying to get at
could be more generally useful.
>In conclusion, I support the general idea but cannot support the particular
>wording of the current version of the proposal. When I started writing
>this message, I was going to include a complete revision of the proposal,
>but I have run out of energy.
If general feeling seems to indicate, I can reword the proposal along
the lines of MAKE-LOAD-TIME-EVAL, or clean up the existing proposal.
One additional problem with the existing proposal is the need and
desire to avoid introducing additional special forms into Common Lisp.
Any other comments?
jak
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Re: Issue ADJUST-ARRAY-DISPLACEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 12:47:34 PDT
Date: 11 Jun 87 12:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue ADJUST-ARRAY-DISPLACEMENT
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 10 Jun 87 23:09 EDT
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of
Sun, 7 Jun 87 19:29 EDT
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870611-124734-1571@Xerox>
I intend to revise and recirculate this issue before mailing to X3J13
(unless someone else volunteers to do the revision first.)
Does anyone object to specifying that ADJUST-ARRAY, if no :DISPLACED-TO
argument is given, will always result in a non-displaced array, even if
the array was displaced before?
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Re: Issue: FORMAT-COMMA-INTERVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:44:03 PDT
Date: 11 Jun 87 13:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: Pavel.pa's message of Wed, 10 Jun 87 18:03:40 PDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-134403-1660@Xerox>
If there are no objections, I propose releasing FORMAT-COMMA-INTERVAL to
X3J13, changing "the last" to "one of the last". I'll hold off on this
one until Monday.
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:22:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:01:24 PDT
Date: 11 Jun 87 15:00 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-150124-1787@Xerox>
Since the "including NIL" was inflammatory, and the proposal reads
nicely and unambiguously without it, I removed it from the Proposal. I
moved the "the cleanup committee generally supports" to the beginning of
the discussion rather than the end, to make sure that it is clear that
it refers to the proposal rather than some sentence of the discussion. I
changed "The cleanup committee considered, but rejected, a proposal to
exclude NIL ..." to say "but did not adopt".
I intend to mail this to x3j13 on Monday unless I hear objections.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place. In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in. If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.
The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:22:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:44:56 PDT
Date: 11 Jun 87 14:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: IF-BODY (Version 5)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sat,
2 May 87 14:43 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-144456-1759@Xerox>
I am having difficulty releasing IF-BODY, because of its length and
form. I think it is an embarassment and will cause an uproar if
presented in its present form.
I wouldn't mind a proposal that contained all of the words and
discussions of this one, but in the discussion section. I think most of
the other issues can be summarized succinctly and fairly.
While I hate to do this (and possibly it is a mistake) I am going to
attempt to do the surgery to put Version 5 in a releasable form
(although we are all sick of it). You'll probably hate me for it, but
I'd rather not foist it in its current form on the community.
∂11-Jun-87 1726 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Jun 87 17:26:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 170782; Thu 11-Jun-87 20:17:58 EDT
Date: Thu, 11 Jun 87 20:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870611-124734-1571@Xerox>
Message-ID: <870611201753.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Unless there's a compelling reason not to, I think it's important to always
make ``keyword NIL'' mean the same as not having supplied the keyword. There's
only a few cases where we violate this and if anything we should be working
on reducing the number of cases.
I think :DISPLACED-TO NIL should copy into a new area and give back a
non-displaced array, so I agree that this should be the behavior in the
case of omitting :DISPLACED-TO.
Since we're guaranteeing that levels of array displacement will never
be optimized out, it would seem to me reasonable to provide functions
to ask an array whether it is displaced, and if so to what at what index.
Perhaps:
ARRAY-DISPLACED-TO array [Function]
Returns the array to which the argument <array> is displaced, or
NIL if the argument <array> is not displaced.
ARRAY-DISPLACED-INDEX-OFFSET array [Function]
Returns the displaced-index-offset of the argument <array>, or
NIL if the argument <array> is not displaced. (If <array> has been
displaced to another array, but no displaced-index-offset was specified,
this function returns 0.)
Example:
(ADJUST-ARRAY THE-ARRAY THE-NEW-DIMENSIONS
:DISPLACED-TO (ARRAY-DISPLACED-TO THE-ARRAY)
:DISPLACED-INDEX-OFFSET (ARRAY-DISPLACED-INDEX-OFFSET THE-ARRAY))
These operations might also be of use to certain people wanting to write
highly optimized array manipulation code that wanted to accept arguments
which might be displaced arrays, but which didn't want to have to incur the
displacement overhead internally.
∂11-Jun-87 1842 Masinter.pa@Xerox.COM Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:42:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 16:05:20 PDT
Date: 11 Jun 87 16:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870611-160520-187@Xerox>
Please pay special attention to the issues marked *. I believe these
are the ones where last-minute wording changes might have invalidated
consensus. I hope I was adequately cautious in my mailing to X3J13.
I am going to be on vacation starting next Wednesday until right before
the X3J13 meeting.
David Moon has kindly offered this group a meeting room at Symbolics on
Monday. I suggest we start at 10:00, with a break for lunch, and plan on
ending around 4:00 PM.
We have a request from Skona Brittain (an X3J13 member from
Microcomputer Systems Consultants in Santa Barbara) to join the cleanup
committee. Unfortunately, she does not have mail access. While it seems
unlikely that anyone not on the net could usefully participate, I am
reluctant to turn down enthusiastic volunteers.
!
In this file: EB = Benson, GLS = Guy Steele,
PC = Pavel Curtis, KMP = Kent Pitman, SEF = Scott Fahlman,
LMM= Larry Masinter
[name/initials] position => person had position on ballot.
[all] position => everyone who voted on this issue voted this way
position on ballot.
Withdraw = "Place on hold pending resolution of comments already
received."
! released
* nearly ready for release
! Proposal format (Version 11)
Released 11-Jun-87 13:07:17
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Comments & edits after ballot.
Not ready for release
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
comments from Moon, JonL, SEF against current form
[EB, PC, SEF] Withdraw
Not ready for release
! AREF-1D (Version 5)
(Add a new function for accessing arrays with row-major-index)
[all] Version 2 with name => ROW-MAJOR-AREF
Version 5 released 11-Jun-87 13:07:50
* ASSOC-RASSOC-IF-KEY (Version 1/22-Apr-87)
(Extend ASSOC-IF, etc. to allow :KEY)
[EB, GLS, KMP] Release as is
[LMM] ASSOC-IF has CAR for KEY?
Reply?
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
(Version 4, submittted by SEF was withdrawn --
consider DRIBBLE as a separate issue)
Version 3 released.
Version 6 released 11-Jun-87 13:15:29
! DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 released 11-Jun-87 13:30:32
! DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 released 11-Jun-87 13:30:22
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
[EB, GK] DO-SYMBOLS:ALLOWED
[PC, Moon, LMM] something like :ADD-KEYWORD
not ready for release
ENVIRONMENT-ARGUMENTS (Version 1)
Separated into other proposals.
Withdrawn.
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Not yet submitted.
! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Released 11-Jun-87 13:36:10
! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
Version 3 released.
Version 4 released 11-Jun-87 13:44:27.
* FORMAT-COMMA-INTERVAL (Version 1/10 June)
Ready for release?
FORMAT-NEGATIVE-PARAMETERS
Not yet submitted; mail 19-May by KMP
! FORMAT-OP-C (Version 5/ 11-Jun-87 14:00:19)
(What does ~C do?)
Release to X3J13
FUNCTION-TYPE (Version 4/ 29-May-87)
(Change definition of FUNCTIONP, function type ...)
[EB, GLS, PC] Release as is [GK] Stronger [Moon] OK after comments
addressed
[KMP] break in two, so I could
support the half I like and only grump about the parts I don't
want stronger warning
[SEF] 2-option, 3-option version
Not ready for release
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
Submitted by Pitman 23-Apr-87
In discussion: merge with other controls for
unsolicited messages?
! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
(Environment argument for GET-SETF-METHOD)
[EB, GLS, PC, Moon, SEF] Release as is
[GK] Ballot says comments follow, but no comments?
[KMP] NIL as null lexical environment
Released 11-Jun-87 14:18
* IF-BODY (Version 5, 29 Apr 87)
(extend IF to implicit progn if more than one ELSE form?)
General agreement to recommend against.
While EB, PC, Moon voted to wait for a version that KMP and SEF
agreed was fair, SEF said 5 was fair enough.
LMM will reformat
IGNORE-ERRORS (Version 4, 29-May-87)
[EB, LMM, PC, Moon] Wait for error proposal
[GLS, KMP, SEF] Release as is (but remove "Larry wonders ...")
KMP will release as report from cleanup + error committee
! IMPORT-SETF-SYMBOL-PACKAGE (Version 4/ 29-May-87)
Version 3 Released
Version 5 released 11-Jun-87 14:48:33
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
[EB, GLS, PC, Moon] Release as is (some typos) [SEF] Comments
Ready for release?
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
Moon may rewrite? (Please)
Not ready for release
MACRO-FUNCTION-ENVIRONMENT
Not yet submitted (From ENVIRONMENT-ARGUMENTS)
! PATHNAME-STREAM (Version 2)
[EB, GK, PC, Moon, SEF] Release as is
Released 11-Jun-87 15:03:54
PATHNAME-SYMBOL (Version 2)
[GLS, PC, Moon, KMP, SEF] Release as is
[eb] against, want minority view (needs formatting)
Moon " cover every argument that is called pathname,
filename, file, or new-name
and leave the rest of the ambiguities for another proposal?"
Not ready for release
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
Agreed to be controversial
[EB, GLS, PC, KMP] Withdraw from consideration, await new proposal
Not ready for release
! PRINC-CHARACTER (Version 3)
Released 11-Jun-87 15:35:59
PROCLAIM-LEXICAL (Version 1)
In discussion
Some progress
Need volunteer to merge comments into new version
Not ready for release
PROMPT-FOR (Version 1)
Agreed to be controversial
[EB, PC, Moon, SEF] Withdraw
Not ready for release
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
[PC, SEF] (PUSH FIRST SECOND)
Not yet submitted.
REQUIRED-KEYWORD-ARGUMENTS
("A hole in Common Lisp: RPG/....")
Not yet submitted
REMF-DESTURCTION-UNSPECIFIED (Version 1)
Submitted by DLA
Discussion?
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Version 2 by KMP 28 Apr 87
In discussion, no clear consensus
[EB] Unchanged [PC, KMP, SEF] Undecided
Not ready for release
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Mild for this proposal, but preference for
removing FONT and BITS attribute
[EB] Release as is
[pc, KMP] no, remove bits & font
want fuller character proposal
not ready for release
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
[RPG against, GLS for, SEF reluctant, etc.]
not ready for release
SHARPSIGN-PLUS-MINUS-PACKAGE
Seems like general agreement for :KEYWORD.
Need to remove other options from proposal
not ready for release
SPECIAL-FORM-SHADOW
Is it OK to shadow a special form with FLET, LABELS?
Not yet submitted
(From ENVIRONMENT-ARGUMENTS)
TAILP-NIL
Not yet submitted.
Needs volunteer to format.
Notes from Moon
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
In discussion
Need volunteer to summarize issues
∂11-Jun-87 1842 Masinter.pa@Xerox.COM Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:42:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:45:14 PDT
Date: 11 Jun 87 15:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-154514-183@Xerox>
At an earlier meeting, there was some discussion over registering the
list of "public" features and "system" packages so that different
implementations would not step over each other in their use of them.
(For example, Xerox uses XCL:, as did one of the X-in-Common-Lisp
modules. User code that explicitly referenced XCL:DRAW would have to be
edited explicitly.)
This seems actually to get more at the heart of the matter than the
current proposals for #+- and the like.
Perhaps we could discuss this at our meeting?
∂11-Jun-87 1846 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:46:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 16:49:30 PDT
Date: 11 Jun 87 16:49 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 10 Jun 87
23:25 PDT
To: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-164930-206@Xerox>
I missed this message, sorry.
I think we have agreement to release the form of FUNCTION-TYPE which
allows implicit coercion in FUNCALL and APPLY. Can someone produce a
new version of the proposal? It would be good if we could release it by
X3J13.
Richard, I think that your position about the EULisp community is
unnecessarily extreme, but I will address that in a separate message.
∂11-Jun-87 2045 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D (Version 2)
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87 20:45:45 PDT
Received: by navajo.stanford.edu; Thu, 11 Jun 87 20:42:32 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA26428; Thu, 11 Jun 87 18:26:44 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA14620; Thu, 11 Jun 87 18:28:39 PDT
Date: Thu, 11 Jun 87 18:28:39 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706120128.AA14620@bhopal.edsel.uucp>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 2 Jun 87 01:22 EDT <870602012209.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 2)
Your note of 2-Jun says that I "supported" the ammended version. I don't
remember voting any issue, or even particularly arguing for one point of
view or the other. The relevant comment from me was merely that GLS's
"clarifications" of 6-Dec-86 used ROW-MAJOR-AREF for the same thing your
proposal was using AREF-1D for, and that Lucid had already implemented it
under the 6-Dec-86 name. Wouldn't it be better to mention the 6-Dec-86
"Clarifications" rather than deduce my (non-voting) support?
-- JonL --
∂11-Jun-87 2121 FAHLMAN@C.CS.CMU.EDU Status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87 21:21:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Jun 87 00:21:02-EDT
Date: Fri, 12 Jun 1987 00:20 EDT
Message-ID: <FAHLMAN.12309805464.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Status
In-reply-to: Msg of 11 Jun 1987 19:05-EDT from Masinter.pa at Xerox.COM
With regard to the request from Skona Brittain, I think we should see
what can be done to get her arpanet access via dialup to some nearby
machine. However, as long as she is not able to receive and send
netmail, I don't think she should be considered part of this committee.
It means that someone would have to take the responsibility for sending
this stuff out in hardcopy, and it means that we would have to wait
around for arbitrarily long periods waiting for her input and votes. I
don't think we can even invite her to the face-to-face meetings -- she
would be missing too much context.
She is of course welcome to submit issues and to participate in the
final votes -- all X3J13 members get to do that.
-- Scott
∂12-Jun-87 0939 Masinter.pa@Xerox.COM Re: Hm
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 09:39:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 09:38:06 PDT
Date: 12 Jun 87 09:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Hm
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 12 Jun 87
01:32 PDT
To: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
to: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870612-093806-1562@Xerox>
JonL: regarding your support of ROW-MAJOR-AREF, I interpreted your
wording "Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this
addition seemed very natural and `called for'. So Lucid Common Lisp has
had it available since shortly thereafter. " to be support.
If you don't intend to support this proposal and want to raise some
objection to it, I can send out an amended version of the proposal with
your objections contained in it.
Richard (and others):
In the status report, the initials [rpg], [jonl] etc. were only my
summary of the ballots, e.g., if you answered the mail with
***BALLOT***. They don't reflect any additional comments or positions
in separate mail.
∂12-Jun-87 1040 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 10:40:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 10:24:45 PDT
Date: 12 Jun 87 10:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870612-102445-1632@Xerox>
My idea with FUNCTION-TYPE is to bring out a proposal which includes the
automatic coercion of symbols to functions, puts forward the removal of
the coercion in the discussion section (as possibly a new proposal) and
for this to be a discussion item at X3J13. It will be hard for it to be
a discussion item if it doesn't go out in the mail. The discussion
section of the proposal should say something like "The cleanup committee
generally supports this proposal, as far as it goes. Some members of the
committee feel strongly that it does not go far enough. We believe this
is an issue which deserves wider discussion in the community, since it
affects the position of X3J13 and Common Lisp with respect to the EuLisp
community."
Is that OK?
I'm trying hard to keep the administration of this uncolored by my own
opinion on the issues.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Here's my opinion on the issue:
I promised a message on the issue of compatibility and our negotiating
position with EuLisp and ISO. I am finding it very difficult to compose.
The X3J13 statement clearly includes as one of the options we are able
to take is to propose a layered implementation strategy, i.e., that
there are simpler subsets of Common Lisp, full Common Lisp, and
supersets of full Common Lisp.
I believe that our current goal is to properly remove the ambiguities in
full Common Lisp and, where warrented, consider minor enhancements.
When dealing with subsets and supersets, I think that we also have
additional goals, that the layers properly nest (programs in a subset
will run in a superset), that it be possible (either by static analysis
or runtime) to tell whether a program in a superset would run in a
subset, etc.
I believe the proper position with regard to EuLisp and ISO's desire for
a simpler language as a standard is for it to be a subset.
In the case of the FUNCTION-TYPE issue, it is critical that the FUNCTION
type be well specified in full Common Lisp, if it is a first-class type
in any subset. Otherwise, programs which depended on a clean dynamicly
accurate FUNCTIONP would not run in (arbitrary) full Common Lisp
implementations.
However, there is no need to remove the automatic coercion of symbols
and LAMBDA expressions in FUNCALL, APPLY and friends. It is certainly
possible to have a subset which does not include coercions which the
full language provides.
With regard to simplicity and coercions, the automatic coercion of
symbols and lambda expressions to their designated functions is not a
lot more complex than the coercion of (symbols?) and strings to
pathnames, or possibly even integers to complex floats.
∂12-Jun-87 1906 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 19:06:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Jun 87 21:36:21-EDT
Date: Fri, 12 Jun 1987 20:12 EDT
Message-ID: <FAHLMAN.12310022293.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE
In-reply-to: Msg of 12 Jun 1987 13:24-EDT from Masinter.pa at Xerox.COM
I think that if we agree to settle on the coercing version of this
proposal now and to discuss the more radical version later, we almost
guarantee that the radical version will not be seriously considered in
our lifetimes. We will have established a new status quo that is
tolerable, more or less, and it will be very hard to move away from that
to something better (if we decide it is indeed better).
I think that it would be best to present both plans to X3J13 and to
discuss the merits of each at the meeting, and then if the coercing
version is the best we can do, so be it; we shouldn't kid ourselves that
a more radical cleanup of this issue will be considered later.
-- Scott
∂12-Jun-87 1943 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-DISPLACEMENT
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 19:43:11 PDT
Received: by navajo.stanford.edu; Fri, 12 Jun 87 19:40:39 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA01678; Fri, 12 Jun 87 17:25:25 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA01339; Fri, 12 Jun 87 17:27:22 PDT
Date: Fri, 12 Jun 87 17:27:22 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706130027.AA01339@bhopal.edsel.uucp>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 11 Jun 87 20:17 EDT <870611201753.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
You suggest adding two new functions to Common Lisp:
ARRAY-DISPLACED-TO array [function]
ARRAY-DISPLACED-INDEX-OFFSET array [Function]
Did you overlook the function specified in the 6-Dec-85 "Clarifications"?
DISPLACED-ARRAY-P array [Function]
"which takes an array and returns NIL and 0 if it is not displaced or the
array displaced to and the displaced-index-offset if it is displaced."
Wouldn't it be much better to adopt the "Clarifications" approaches, where
appropriate, since some, if not several, implementations have already
implemented them?
-- JonL --
∂12-Jun-87 2255 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 22:55:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 22:54:31 PDT
Date: 12 Jun 87 22:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
12 Jun 87 20:12 EDT
To: Fahlman@C.CS.CMU.EDU
cc: Masinter.pa@Xerox.COM, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870612-225431-2538@Xerox>
Puerhaps I wasn't clear. I think that the discussion of the coercion of
FUNCALL and APPLY is a central, and very important to discuss, at this
X3J13. However, I think it is separable from the issue of the FUNCTION
type, and the changes to FUNCTIONP and TYPEP of FUNCTION. And, it
seems valuable to separate them, since, while they are both compatible
changes, there is not necessarily any correlation between whether one
supports one and the other, since their justifications and motivations
are not identical.
My proposal is to separate them. One issue is FUNCTION-TYPE. What is
the other issue called? I had tentatively named it FUNCTION-COERCION. A
proposal just arrived from Will Clinger, with selective linking as the
central theme (I alluded to this in an earlier message.) I will mail
this out in a separate message (EVAL-DEFEATS-LINKER). If your sentiment
is that we should not release one issue without the other, I agree, it
seems poor form and might let one get lost in the face of the other. If
you would like to keep them together in the same proposal, please
explain.
Thanks,
Larry
∂12-Jun-87 2256 Masinter.pa@Xerox.COM Issue: EVAL-DEFEATS-LINKER
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87 22:55:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 22:55:21 PDT
Date: 12 Jun 87 22:55 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EVAL-DEFEATS-LINKER
To: cl-cleanup@Sail.stanford.edu
cc: willc%tekchips.tek.com@RELAY.CS.NET
Message-ID: <870612-225521-2539@Xerox>
Date: 12 Jun 87 15:36:10 PDT (Fri)
Issue: EVAL-DEFEATS-LINKER
References: Functions (p32); FUNCTIONP (p76); APPLY (pp107-108);
FUNCALL (p108); #. (pp355-356); #, (p356)
Category: CHANGE
Edit history: 12-Jun-87, Version 1 by Clinger
Problem description:
It appears to be impossible to write a selective linker for Common Lisp
that is both reliable and effective. The reason is that most programs
must call APPLY, FUNCALL, or READ, which potentially call SYMBOL-FUNCTION
or EVAL, which must be regarded as potential references to any standard
or user-defined Common Lisp procedure. At a minimum, therefore, the
entire Common Lisp library gets linked into the deliverable application.
Proposal (EVAL-DEFEATS-LINKER:FLUSH-GRATUITOUS-EVALS):
Change the definition of the function type to exclude symbols and lists.
Change the definition of FUNCTIONP to be false of symbols and lists.
Change the definitions of APPLY and FUNCALL so it is an error to pass
them a symbol or a list as their first argument.
Functions such as MAPCAR that are defined by reference to the concept of
function or by reference to APPLY and FUNCALL would be affected by these
changes as well, but it would not be necessary to change their
written specification.
Remove the #. and #, dispatching macro characters from the standard reader
syntax. Require the interpreter, compiler, and interactive loader to use
a reader syntax that has been extended by adding the #. and #, dispatching
macro characters.
Test Case:
The executable file for the following program is comparable in size to
a complete Common Lisp system.
(DEFUN MAIN ()
(PRINT (EVAL (READ))))
A selective linker should, however, be able to link the following program
into a relatively small executable file.
(DEFUN MAIN ()
(PRINT (APPLY (FOO) (READ))))
(DEFUN FOO ()
(LET ((BIAS (RANDOM 1000)))
#'(LAMBDA (&REST ARGS) (+ BIAS (APPLY #'+ ARGS)))))
Currently selective linkers have difficulty with the preceding program
because they must also make programs like the following work, where FOO
"computes" an arbitrary function. Under the proposal, the only ways
to compute an arbitrary function would be through explicit use of EVAL
or SYMBOL-FUNCTION et cetera.
(DEFUN MAIN ()
(PRINT (APPLY (FOO) (READ))))
(DEFUN FOO () (READ))
Rationale:
Selective linking is essential for most industrial applications. Symbols
and lambda expressions are regarded as functions for historical reasons
only. The description of the #, dispatching macro character on p356
suggests that both #. and #, are intended for use in code, not in data
to be read by an application program.
Current practice:
Hardly any implementations of Common Lisp attempt to remove unnecessary
code from a deliverable application. Those that do appear to ignore the
problems posed by the third test case, and are therefore unreliable.
That is, they are incorrect because they behave as though this proposal
has been adopted when it has not.
Adoption Cost:
Implementations do not actually have to change APPLY and FUNCALL, since
they would not have to signal an error when passed a symbol or list.
Implementations that rely on #. and #, in non-code data would suffer
a conversion cost, but it seems unlikely that any implementations do this.
Cost of non-adoption:
Selective linking will continue to be unavailable or unreliable.
Benefits:
The availability of reliable selective linkers will make Common Lisp suitable
for a much braoder range of applications.
Conversion Cost:
Programs for which reliable selective linking is unimportant (that is,
essentially all current Common Lisp programs) can be converted by
redefining APPLY and FUNCALL and by defining the #. and #, dispatching
character macros. This will be referred to below as the trivial conversion.
Programs for which reliable selective linking is important, if any exist,
are presumably written in a style that needs no conversion.
To convert an existing program into a style that can be linked selectively,
it is necessary to examine all calls to APPLY, FUNCALL, MAPCAR, and other
functions that take functions as arguments. Where the argument expression
is of the form (FUNCTION f), no conversion is necessary. Where the first
argument is of the form (QUOTE f), it should be changed to (FUNCTION f).
Where the first argument is of neither of these two forms, human intervention
will be necessary. It seems likely that most calls will have first arguments
of the form (FUNCTION f) or (QUOTE f), so this conversion can be automated
substantially but not completely.
As with all conversions, arguments to EVAL must be analyzed specially.
Since uses of EVAL generally defeat selective linking, however, it is
clear that programs that make extensive use of EVAL were not intended
to be passed through a selective linker. Hence the trivial conversion
should suffice for such programs.
If the program reads data from files, then it may be necessary to scan the
files for occurrences of #. and #,. If any occurrences are found, they
will have to be removed. It seems clear, however, that no program intended
for selective linking will rely on #. and #, in data files.
Esthetics:
This proposal simplifies Common Lisp by removing weird special cases that
contribute to the language's reputation for inefficiency.
Discussion:
This is a good example of the practical importance of aesthetics in language
design. The difficulties implementors face in writing a selective linker
for Common Lisp are inherent in the current language definition. It is
better to fix the language than to postulate sufficiently clever linkers.
While this proposal will make it possible to construct selective linkers,
it will not make it trivial. In many implementations, for example, the
data structure for each symbol contains among other things a pointer to
the symbol's home package, a value cell, and a function cell. In such an
implementation each symbol may represent a potential reference to the value
cell of any symbol accessible from its home package. Implementations that
care about selective linking may have to break such links.
Scheme proves that it is possible to design a Lisp that can be linked
selectively. Reliable selective linkers have been written for T and for
MacScheme, and possibly for other implementations as well.
∂13-Jun-87 0042 edsel!bhopal!jonl@navajo.stanford.edu Hm
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Jun 87 00:42:20 PDT
Received: by navajo.stanford.edu; Sat, 13 Jun 87 00:39:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA02160; Fri, 12 Jun 87 23:04:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA01882; Fri, 12 Jun 87 23:06:05 PDT
Date: Fri, 12 Jun 87 23:06:05 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706130606.AA01882@bhopal.edsel.uucp>
To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!RPG%SAIL.STANFORD.EDU@navajo.stanford.edu,
navajo!cl-cleanup%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 12 Jun 87 09:37 PDT <870612-093806-1562@Xerox>
Subject: Hm
Goodness no, by no means do I want to raise an objection to the AREF-1D
proposal. I only wanted to make it perfectly clear that my interest
was not so much "support" or "criticism" of the overall proposal, but
a reminder that the 6-Dec-85 "Clarifications" had already addressed the
functional issue, and had already picked the name ROW-MAJOR-AREF. I guess
I wasn't so "perfectly clear".
Eric Benson has already cast the Lucid vote in support of the proposal.
-- JonL --
∂14-Jun-87 1136 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Jun 87 11:36:04 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 172424; Sun 14-Jun-87 14:28:35 EDT
Date: Sun, 14 Jun 87 14:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
To: edsel!bhopal!jonl@navajo.stanford.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8706130027.AA01339@bhopal.edsel.uucp>
Message-ID: <870614142825.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 12 Jun 87 17:27:22 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
You suggest adding two new functions to Common Lisp:
ARRAY-DISPLACED-TO array [function]
ARRAY-DISPLACED-INDEX-OFFSET array [Function]
Did you overlook the function specified in the 6-Dec-85 "Clarifications"?
DISPLACED-ARRAY-P array [Function]
"which takes an array and returns NIL and 0 if it is not displaced or the
array displaced to and the displaced-index-offset if it is displaced."
If you code up the same example as I sent in my last message using
the function DISPLACED-ARRAY-P, you'll see that it's a lot more clumsy.
To me, the presence of these two functions makes the need for
DISPLACED-ARRAY-P seem unnecessary while at the same time making
code that actually needs this information look a lot better.
Wouldn't it be much better to adopt the "Clarifications" approaches, where
appropriate, since some, if not several, implementations have already
implemented them?
I certainly admit that I didn't look in the clarifications before
sending that message. I should have.
Ultimately, however, the clarifications are just one person's opinion (albeit
the opinion of one who is very highly respected). They still have to get voted
on just as do anyone else's suggestions. And while I admit that we shouldn't
try to gratuitously perturb things that people have already implemented where
it is reasonable to avoid doing so, I don't think we are obliged to
unconditionally support an implementation's decision to introduce these
primitives `prematurely'.
As it happens, I don't like functions with predicate-sounding names being
used for non-predicate values, so I'm not sure that I would have really
wanted to go with this clarification if I had a choice. eg, whenever I
use DIGIT-CHAR-P for value, I do
(DEFUN DIGIT-WEIGHT (&REST ARGS) (APPLY #'DIGIT-CHAR-P ARGS))
and use DIGIT-WEIGHT instead. I find that expressions like
(+ (* VALUE RADIX) (DIGIT-CHAR-P CHAR))
look really awful in practice and can't bring myself to write them.
∂15-Jun-87 1919 Masinter.pa@Xerox.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:19:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 13:23:44 PDT
Date: 15 Jun 87 13:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 22 Apr 87 15:14 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870615-132344-158@Xerox>
I've been unable to find any other implementation (outside of symbolics)
that has ASSOC-IF-KEY. I looked at Spice, Xerox and VaxLisp. I'm uneasy
saying that the others are "split down the middle" if they aren't.
I tried to generate a test case. Can you think of something more
illuminating than
(ASSOC-IF #'ZEROP '(("ABC" . 3) ("E" . 4) ("" . 7)) :KEY #'LENGTH)
=> ("" . 7)
∂15-Jun-87 1920 Masinter.pa@Xerox.COM READ TODAY: Cover letter for mailing to X3J13
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:20:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 14:44:09 PDT
Date: 15 Jun 87 14:29 PDT
From: Masinter.pa@Xerox.COM
Subject: READ TODAY: Cover letter for mailing to X3J13
To: cl-cleanup@sail.stanford.edu
Message-ID: <870615-144409-103@Xerox>
I want to mail this tomorrow, as I must get the hardcopy version out,
and I am leaving town. Please reply asap. Also, while there have been a
couple of NACKs, no ACKs on the Monday meeting, 10 AM at Symbolics. Who
will attend?
Scott is working on FUNCTION-TYPE, and Kent on IF-BODY. It seems
important to get those versions in the hands of X3J13 in advance of the
meeting, so that there can be some meaningful discussion. I have
tentatively put new version numbers down with today's date.
If the versions can be distributed to cl-cleanup today, there's a chance
of mailing them with the other hardcopy versions tomorrow (and I will
change the cover letter.) Otherwise, they will have to be distributed at
the meeting.
!
Dear X3J13 members:
Enclosed are several proposals from the cleanup committee for your
examination. The committee has been "meeting" via electronic mail. For
each proposal, there has been an average of 10-15 messages.
In most cases, the cleanup committee has explicitly endorsed the
proposal -- i.e., we all think it is a good idea. In some cases, while
the committee has generally agreed that the proposal is a good idea,
there hasn't been sufficient time to obtain agreement about the exact
form of the proposal; in those cases, while an earlier version was
circulated among the cleanup committee. In most of these proposals, some
earlier version was circulated to the committee and explicitly voted on.
In a few cases (identified in the proposal) there has been a great deal
of disagreement, but that we generally thought that we should bring the
matter to the attention of the larger group, for discussion and
guidance.
For your information, I have listed below all of the issues currently
under consideration, with an extremely brief description of the issue.
If anyone is interested in further details, or in joining the cleanup
committee, please let us know (CL-CLEANUP@Sail.stanford.EDU). Those
issues which are included in this mailing (and were mailed electronicly)
are marked with a !. Those marked with * were nearly ready for release,
but a final version is not available. We hope to have final versions of
these at the meeting.
!
! Proposal format (Version 11)
Format for proposals to the cleanup committee.
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs no :displaced-to.
Not ready for release
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release
! AREF-1D (Version 5/11 Jun 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 released
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Almost ready for release
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 3 released.
Version 6 released 11-Jun-87.
! DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 released 11-Jun-87 13:30:32
! DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 released 11-Jun-87 13:30:22
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available
not ready for release
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Not ready for release
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Defer to condition system?
Not yet submitted.
! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Released 11-Jun-87
! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 3 released.
Version 4 (re-)released 11-Jun-87 13:44:27.
* FORMAT-COMMA-INTERVAL (Version 1/10 June)
(Allow another argument to ~D etc to paramerize digits between commas)
Almost ready for release
FORMAT-NEGATIVE-PARAMETERS
Not yet submitted; mail 19-May by KMP
! FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Released 11-Jun-87
* FUNCTION-TYPE (Version 4/ 15-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Not quite ready for release
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release
! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 released 11-Jun-87
* IF-BODY (Version 7, 15-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Not quite ready for release
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee
! IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 3 Released
Version 5 released 11-Jun-87
! KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
( &KEY arguments not in keyword package?)
Version 6 released 15-Jun-87
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
Not yet submitted (From ENVIRONMENT-ARGUMENTS)
! PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Released 11-Jun-87 15:03:54
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release
! PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Released 11-Jun-87 15:35:59
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
[PC, SEF] (PUSH FIRST SECOND)
Not yet submitted.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, no proposal submitted
REMF-DESTURCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
not ready for release
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
not ready for release
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
not ready for release
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS?)
In discussion, no proposal submitted yet
TAILP-NIL
(Operation of TAILP given NIL)
Not yet submitted.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release
∂15-Jun-87 1938 FAHLMAN@C.CS.CMU.EDU READ TODAY: Cover letter for mailing to X3J13
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:38:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 15 Jun 87 22:37:15-EDT
Date: Mon, 15 Jun 1987 22:37 EDT
Message-ID: <FAHLMAN.12310835145.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: READ TODAY: Cover letter for mailing to X3J13
In-reply-to: Msg of 15 Jun 1987 17:29-EDT from Masinter.pa at Xerox.COM
The second sentence in this paragraph isn't a sentence, and I can't
figure out what it's trying to say. Something got garbled.
In most cases, the cleanup committee has explicitly endorsed the
proposal -- i.e., we all think it is a good idea. In some cases, while
the committee has generally agreed that the proposal is a good idea,
there hasn't been sufficient time to obtain agreement about the exact
form of the proposal; in those cases, while an earlier version was
circulated among the cleanup committee. In most of these proposals, some
earlier version was circulated to the committee and explicitly voted on.
In a few cases (identified in the proposal) there has been a great deal
of disagreement, but that we generally thought that we should bring the
matter to the attention of the larger group, for discussion and
guidance.
I'm not sure I'd mention the "not yet submitted" issues at all in this
list. If the idea is to solicit proposals on these issues from outside
the cleanup committee, that's OK, but in that case we need to describe
the problem better, and I would argue that this should be done in a
separate communication. I don't feel passionately about this, but I do
think it's a bit confusing.
Otherwise, this looks OK to me.
-- Scott
∂15-Jun-87 2042 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: EVAL-DEFEATS-LINKER
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jun 87 20:42:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 173727; Mon 15-Jun-87 23:41:49 EDT
Date: Mon, 15 Jun 87 23:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EVAL-DEFEATS-LINKER
To: Masinter.pa@Xerox.COM, willc%tekchips.tek.com@RELAY.CS.NET
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <870612-225521-2539@Xerox>
Message-ID: <870615234142.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 12 Jun 87 22:55 PDT
From: Masinter.pa@Xerox.COM
Proposal (EVAL-DEFEATS-LINKER:FLUSH-GRATUITOUS-EVALS):
I don't think this is a good choice of name, because only the third paragraph
of the proposal has anything to do with EVAL. EVAL-DEFEATS-LINKER:CLOSED-SYSTEM
would be a better name, and EVAL-DEFEATS-LINKER:REMOVE-FUNCTION-COERCION would
be even better if the readtable part is dropped as I suggest below. This is
nit-picking, of course.
Change the definition of the function type to exclude symbols and lists.
Change the definition of FUNCTIONP to be false of symbols and lists.
The above two lines are redundant with the FUNCTION-TYPE proposal. I guess
that means that this proposal has FUNCTION-TYPE as a prerecquisite.
Change the definitions of APPLY and FUNCALL so it is an error to pass
them a symbol or a list as their first argument.
Functions such as MAPCAR that are defined by reference to the concept of
function or by reference to APPLY and FUNCALL would be affected by these
changes as well, but it would not be necessary to change their
written specification.
This is the first cogent argument I have seen for why APPLY and FUNCALL should
not coerce names of functions to functions. I'm glad to see the discussion
getting real.
One way to address the conflict between compatibility with existing
programs and the proposed automated subsetting of Common Lisp by observing
what features are manifestly used by a given program, would be to note the
use of the phrase "is an error". This allows all existing implementations
to agree on an extension to Common Lisp to support coercion of function
names to functions, i.e. to agree to continue to do what they do now, while
not requiring future implementations to support that. Programs that exploit
that feature would no longer be portable in law, but would remain portable
in practice, which seems like a desirable state of affairs.
These existing implementations could also agree on a switch that disables
the extension, to facilitate portability to implementations that lack the
extension. I have to caution, however, that implementing such switches as
dynamic variables generally does not work in implementations where the
operating system is written in Lisp; we have some distasteful experience
with that in the areas of case-sensitivity in string comparison and
NIL-sensitivity in CAR and CDR. Implementing the switch in a lexical way,
for instance by providing a package containing alternate versions of
FUNCALL, APPLY, and every CL function that calls FUNCALL or APPLY, would
avoid this problem. There may be other techniques that are more
appropriate than switches. Unfortunately reliance on coercion from
function names to functions is not, in general, detectable at compile time.
If it was detectable at compile time, this whole linker issue would not
have arisen.
Remove the #. and #, dispatching macro characters from the standard reader
syntax. Require the interpreter, compiler, and interactive loader to use
a reader syntax that has been extended by adding the #. and #, dispatching
macro characters.
I see no reason to include this third part in the proposal. Common Lisp already
provides ways to make customized readtables, and applications that want to run
in stripped-down Lisps can use those mechanisms to make readtables that don't
contain #. and #, and can inform their linker that they are using those mechanisms.
The proposal should mention the existence of the #. loophole, of course.
Isn't #S a bit of a loophole, also, although not quite as bad?
I have thought of one additional loophole; perhaps the best way to describe it
is with an example.
(defvar *funcall-loophole*)
(deftype funcall ()
`(satisfies ,*funcall-loophole*))
(defun funcall-the-old-way (symbol argument)
(let ((*funcall-loophole* symbol))
(typep argument 'funcall)))
(funcall-the-old-way '1+ 5) => 6
Perhaps a linker can be written to detect the presence of DEFTYPEs complex
enough that they could be this loophole. I could have written this without
using any special variables, and without using DEFTYPE; I just put those in
to make it look more complicated and thus harder to detect at compile time.
The key point here is that the SATISFIES type-specifier is defined to call
SYMBOL-FUNCTION. I don't think we want to change that.
∂15-Jun-87 2140 Moon@STONY-BROOK.SCRC.Symbolics.COM READ TODAY: Cover letter for mailing to X3J13
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jun 87 21:40:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 173769; Tue 16-Jun-87 00:30:59 EDT
Date: Tue, 16 Jun 87 00:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: READ TODAY: Cover letter for mailing to X3J13
To: Masinter.pa@Xerox.COM, Masinter.pa%Xerox.COM@MC.LCS.MIT.EDU
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870615-144409-103@Xerox>
Message-ID: <870616003052.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 15 Jun 87 14:29 PDT
From: Masinter.pa@Xerox.COM
I want to mail this tomorrow, as I must get the hardcopy version out,
and I am leaving town. Please reply asap.
This didn't make it from Xerox to Stanford until 5 hours after you sent it,
so expect delayed replies. The evidence of a network problem somewhere is
why I'm sending this in a way that should get you three copies.
Also, while there have been a
couple of NACKs, no ACKs on the Monday meeting, 10 AM at Symbolics. Who
will attend?
I haven't heard of this meeting before. Gee, did I arrange it in my sleep?
As far as I know now I can attend, although something might come up.
I have no comments on the letter to X3J13 members, other than seconding
Fahlman's comment on fractured English in one place.
∂16-Jun-87 0159 Masinter.pa@Xerox.COM Re: READ TODAY: Cover letter for mailing to X3J13
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 01:59:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 01:50:08 PDT
Date: 16 Jun 87 01:49 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: READ TODAY: Cover letter for mailing to X3J13
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 16 Jun 87 00:30 EDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <870616-015008-1540@Xerox>
Thanks for the note on the mail delay. They were tinkering with the
mail-server today (moved it to another net), unfortunately, and mail got
temporarily delayed while it was down.
I will fix up the brain-damaged paragraph.
As for the meeting, maybe David was asleep after all?
.....
From: masinter.pa
Date: 31 May 87 20:49:38 PDT
Subject: ballots, meeting, etc.
To: cl-cleanup@sail.stanford.edu
Message-ID: <870531-205005-2070@Xerox>
...
MEETING:
I would like to get together Monday for a subcommittee meeting. I'd like
to discuss some of the more serious open issues and see how much
progress we can make. (PROCLAIM-LEXICAL seems like it might benefit from
a face-to-face discussion.)
What do you think about taking some time to go over the ISSUES.TXT file
and getting some directions on them for us to proceed?
Other agenda items?
...
Date: Tue, 2 Jun 87 00:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ballots, meeting, etc.
To: masinter.pa
In-Reply-To: <870531-205005-2070@Xerox>
Message-ID: <870602002903.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
...
We can get a small (12-person) conference room at Symbolics if a room
elsewhere doesn't materialize. I would need to sign up for it a few
days in advance to be sure to have it all day Monday. We're at the
opposite end of the MIT campus from the Marriot hotel where apparently
people are staying, but it's within walking distance unless the weather
is outrageously hot.
Date: 11 Jun 87 16:05 PDT
From: Masinter.pa
Subject: Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870611-160520-187@Xerox>
...
David Moon has kindly offered this group a meeting room at Symbolics on
Monday. I suggest we start at 10:00, with a break for lunch, and plan on
ending around 4:00 PM.
...
∂16-Jun-87 0608 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87 06:08:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 16 Jun 87 09:07:25-EDT
Date: Tue, 16 Jun 1987 09:07 EDT
Message-ID: <FAHLMAN.12310949843.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (version 5)
I have written up a version of this proposal that presents the two
options we have discussed the most as alternatives. The idea is that we
can perhaps debug this proposal before the Boston meeting, and then have
something concrete and written-down to discuss with the whole X3J13
group. Perhaps that discussion will lead to some consensus or at least
to a clear view of which way the majority of X3J13 wants to go. A mail
ballot after the meeting could make things official in that case. Of
course, it is also possible that people will decide to postpone the
difficult issues and just vote on the type cleanup, without deciding how
the resulting types may be used.
By writing up these two options, I do not mean to preclude others.
However, the only other proposal that has appeared is the one from KMP
that we require a symbol's function cell to accept symbols and lambda
expressions as well as true functions and to return unchanged whatever
was put there. Kent has indicated some ambivalence about whether he
wants to press forward with this option, which has not received any
support from others on the committee. If he does want to press this,
he should write up this option himself, since I don't really understand
the fine points of his position.
Since I won't be there, I have included my own vote at the end. I have
also included what I believe to be RPG's position, since he has made his
views known repeatedly. I'm not sure exactly where the rest of you
stand at present.
Many small things had to be changed to make this a two-option proposal,
so it is probably best for you to consider this a new proposal and read
it over carefully. The major substantive change is in point 3 (now in
two distinct versions). There are also some changes in "cost of
conversion" -- see if you believe my argument that mechanical conversion
of old code to adhere to the strict form of the proposal is possible
and that the result is not significantly less efficient than building
the coercions into FUNCALL and APPLY. Also, look over the discussion
section and see if I have seriously misrepresented anyone's views.
-- Scott
---------------------------------------------------------------------------
Status: To be discussed at X3J13 meeting (?). This is a
tough but important issue that involves some fundamental
trade-offs, so discussion by the whole X3J13 committee
is called for.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
SYMBOL-FUNCTION (pg 90), APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs
the status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Two alternative proposals are presented here:
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION and INTERPRETED-FUNCTION. Note that this is a change
from the current Common Lisp definition which explicitly defines a
COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY. It is no longer legal to pass a symbol or lambda
expression as the functional argument to any of these functions; to do
so "is an error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".
Proposal FUNCTION-TYPE:COERCING-REDEFINITION
This is identical to FUNCTION-TYPE:STRICT-REDEFINITION except for
section 3:
3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments are modified to state
they will accept (true) functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this is not a change to the current behavior of
Common Lisp; the descriptions must be changed to accommodate the new
definition of the FUNCTION data type.
RATIONALE:
Both proposals provide a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
The STRICT-REDEFINITION proposal consistently uses the new, strict
definition of FUNCTION in all of the obvious places.
The COERCING-REDEFINITION proposal cleans up the definition of the
FUNCTION data type, but attempts to minimize the impact on existing code
by providing implicit coercions in FUNCALL and APPLY.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in either of these
proposals, however.
Adoption Cost:
For either proposal, the type predicates would have to be brought into
compliance, but that should require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified
to deal with functions that are not lists (but from which the list form
can be easily reconstructed if necessary).
If STRICT-REDEFINE is adopted, implementations may choose to convert
FUNCALL and APPLY to the new stricter form, but they are not required to
do so. Since the use of a symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension. Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.
BENEFITS:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme.
CONVERSION COST:
The COERCING-REDEFINITION proposal attempts to minimize the impact on
user code by allowing APPLY, FUNCALL, and related functions to accept
symbols and lambda lists, as they currently do. One impact on
user-level code would be a change in the operation of certain type
predicates. Such cases should be relatively easy to find and fix.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
Users might also convert their code by running for a time in an
implementation that still does the coercion in FUNCALL and APPLY, but
that issues a warning message whenever the coercion is actually needed.
This will flag all of the non-portable situations in parts of the
program that have actually been executed during the test period.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code (MACSYMA is one example) depends on this behavior and would
have to be modified if either of these proposals is adopted. However,
such code is not currently portable because many existing Common Lisp
implementations already violate these assumptions. CLtL does not
clearly state what values SETF of SYMBOL-FUNCTION will accept and how
that object may be modified.
Under either proposal, user code which uses COMPILED-FUNCTION-P would no
longer be valid or portable.
AESTHETICS:
Making the concept of a function well-defined will probably be perceived
as a simplification.
The STRICT-REDEFINITION proposal is perceived by most members of the
cleanup committee as the simpler and cleaner of the two proposals. The
COERCING-REDEFINITION proposal adds some complexity in the name of
compatibility.
DISCUSSION:
This has been discussed at great length within the cleanup committee.
All of us agree that the definition of the FUNCTION data type must be
revised, but there is no clear consensus on what to do about the
coercions. Since the cleanup of the type hierarchy is important to the
CLOS group, there is some urgency to this part of the proposal, at
least.
Some committee members (Gabriel and Fahlman) have argued that the strict
form of the proposal is preferable because it is simpler: it defines a
FUNCTION data type and then requires every object used as a function to
be a FUNCTION. The strict proposal requires a somewhat greater
conversion effort for user code, but it seems better to make this effort
once than to live forever with runtime coercion of functional arguments
and the resulting complexity.
Members of the Eulisp group have argued strongly for what amounts to the
STRICT-REDEFINITION proposal. They feel that this would remove one
important difference between their view of Lisp (similar to Scheme in
this instance) and ours.
Moon has argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
Several members of the committee argued in favor of presenting both
proposals to X3J13, since the tradeoff between simplicity and conversion
effort must be discussed by the whole community.
White suggested that if the coercing version of the proposal is
adopted, we might need an APPLICABLE-P predicate that is true of any
object that is legal as a functional argument to APPLY and FUNCALL.
FUNCTIONP will not do this job.
Pitman has argued that items 4 and 5 (either proposal) will break a lot
of code that depends on being able to use lambda expressions and symbols
as function definitions, and that it will be hard to fix such problems.
He may produce a third proposal before the X3J13 meeting that deals with
these problems. He has suggested that we may wish to settle the type
redefinition issues (points 1 and 2 above) now, while deferring a
decision on the more controversial coercion issues.
Fahlman feels that the issues are now clearly drawn and that we should
go ahead and make a decision on the whole package.
Clinger has suggested that the strict form is preferable because it makes
it possible to reduce the total size of a delivered application program.
Only those Common Lisp functions that are actually called need to be
included, but implicit function coercions tends to create loopholes
through which *every* function might be called.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
Fahlman and Gabriel support FUNCTION-TYPE:STRICT-REDEFINITION.
∂16-Jun-87 1338 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: ASSOC-RASSOC-IF-KEY (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Jun 87 13:38:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 174496; Tue 16-Jun-87 16:35:22 EDT
Date: Tue, 16 Jun 87 16:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
To: Masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870615-132344-158@Xerox>
Message-ID: <870616163500.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 15 Jun 87 13:23 PDT
From: Masinter.pa@Xerox.COM
I've been unable to find any other implementation (outside of symbolics)
that has ASSOC-IF-KEY. I looked at Spice, Xerox and VaxLisp. I'm uneasy
saying that the others are "split down the middle" if they aren't.
I think I didn't have access to other lisps in order to try it on the day
I sent that message. If none of the other lisps you know do it, then I'm
happy to say under current practice that only we are known to have implemented
the extension.
I tried to generate a test case. Can you think of something more
illuminating than
(ASSOC-IF #'ZEROP '(("ABC" . 3) ("E" . 4) ("" . 7)) :KEY #'LENGTH)
=> ("" . 7)
Well, I don't like to think of a non-accessor as the :KEY, though this
is technically fine. We should probably give some advice about this in
the sample cleanup template; my feeling is that the test case just has
to illustrate the feature, not motivate it. Under this criterion, the
case above is fine.
The problem with a simple test case is that the need for this only comes up
in real program situations where objects with structured parts appear in
alists. In that case, you might have something like:
(DEFSTRUCT FOO X)
(ASSOC-IF #'IDENTITY '((#S(FOO :X NIL) 3 4) (#S(FOO :X T) 7)) :KEY #'FOO-X)
or
(ASSOC-IF #'PROBE-FILE '((#S(FOO :X "FOO.LSP") 3 4) (#S(FOO :X "BAR.LSP") 7))
:KEY #'FOO-X)
for that matter. In a real program, the #S(...) forms would presumably not be
constant -- they'd be pushed on by programs calling constructors -- and this
latter example doesn't return a constant value across implementations, but it
hopefully gives you a sense of what you can do. Another case might be:
(DEFVAR *KNOWN-PACKAGES* (MAPCAR #'FIND-PACKAGE '("LISP" "KEYWORD")))
(DEFUN KNOWN-PACKAGE-P (PACKAGE) (MEMBER PACKAGE *KNOWN-PACKAGES*))
(ASSOC-IF #'KNOWN-PACKAGE-P '((FROB . FUNCTION) (IF . SPECIAL-FORM))
:KEY #'SYMBOL-PACKAGE)
=> (IF . SPECIAL-FORM)
A situation that seems most familiar to me takes more work to set up:
(DEFUN FULL-DIRECTORY-LIST (WILD-PATHNAME)
"Returns (wild-path (path1 :WRITE-DATE date1 :AUTHOR author1) ...)."
(LET* ((PATHS (DIRECTORY WILD-PATHNAME))
(DATES (MAPCAR #'FILE-WRITE-DATE PATHS))
(AUTHORS (MAPCAR #'FILE-WRITE-DATE PATHS)))
(CONS FILES
(MAPCAR #'(LAMBDA (PATH DATE AUTHOR)
(LIST PATH :WRITE-DATE DATE :AUTHOR AUTHOR))
PATHS DATES AUTHORS))))
In this case, you could imagine a variety of ASSOC-type operations that you
might want to do on the pathname in the car of each list in the cdr of the
result. In general, it's true that you can always write:
(ASSOC-IF #'(LAMBDA (P) (MEMBER (PATHNAME-TYPE P) '("LSP" "L" "LISP")
:TEST #'STRING-EQUAL))
(CDR DIRECTORY-LISTING))
but somehow I find it more aesthetic to see:
(ASSOC-IF #'(LAMBDA (TYPE) (MEMBER TYPE '("LSP" "LISP" "L")))
(CDR DIRECTORY-LISTING)
:KEY #'PATHNAME-TYPE)
so that the key extraction and the predication are separate. This increases
the likelihood that the function in the predicate position will already exist
with some known name. For example, going back to your original example,
there is no function which does (ZEROP (LENGTH x)) but there are functions
ZEROP and LENGTH which work together well in the place where :KEY is provided.
Feel free to extract any part of this message that moves you and add it to
the proposal if you feel it's warranted. Doubtless this text is too long
and rambly to be included as a whole.
∂16-Jun-87 1945 edsel!bhopal!jonl@navajo.stanford.edu READ TODAY: Cover letter for mailing to X3J13
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87 19:45:14 PDT
Received: by navajo.stanford.edu; Tue, 16 Jun 87 19:42:37 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA10855; Tue, 16 Jun 87 18:34:50 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA01141; Tue, 16 Jun 87 18:37:02 PDT
Date: Tue, 16 Jun 87 18:37:02 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706170137.AA01141@bhopal.edsel.uucp>
To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 15 Jun 87 14:29 PDT <870615-144409-103@Xerox>
Subject: READ TODAY: Cover letter for mailing to X3J13
I believe that Dick will attend the Monday meeting at Symbolics on Jun 29.
He is out of town now and won't be back til sometile Thursday.
-- JonL --
∂16-Jun-87 2040 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87 20:40:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 16 Jun 87 23:39:12-EDT
Date: Tue, 16 Jun 1987 23:39 EDT
Message-ID: <FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: willc%tekchips.tek.com@RELAY.CS.NET
Subject: Issue: EVAL-DEFEATS-LINKER
In-reply-to: Msg of 13 Jun 1987 01:55-EDT from Masinter.pa at Xerox.COM
This proposal seems very odd to me.
It is certainly desirable for a Common Lisp implementation to have some
way to create a core image for application delivery that contains only
as much code as that application needs, and not all the rest of Common
Lisp and the associated development environment. I have argued that
this approach to application delivery is much better than trying to
create some small delivery-oriented subset of Common Lisp: it is better
to keep those functions that you actually use and jettison the rest than
to try to guess in advance what subset would be appropriate for a whole
class of appliction.
A normal garbage collection will keep alive all of the functions that
are actually needed by a given application program, either directly or
indirectly. Unfortunately, it will also keep alive every other function
that is globally named by a symbol, even if that symbol is not mentioned
in the application code. Such functions are still "accessible" if there
is a read/eval present, since the user could ask for them by name, so
the garbage collector is not allowed to eliminate them.
We could get rid of these named functions if, by examining all the
application code, we could prove any of the following:
1. The symbol is not mentioned in the application and there is no way to
smuggle it into the system at runtime via calls to read, intern, etc.
2. The function is not called anywhere, and the symbol, though it may be
present, is not converted into a function anywhere. Clinger's proposal
is to make this proof easier by eliminating a large class of implict
symbol-to-function conversions.
3. The function, though it may be present, is not called and is nowhere
passed to EVAL, APPLY, or FUNCALL.
That's one approach to eliminating the unneeded parts of Common Lisp. A
different approach is is to simply ask the user to declare that the
application does not contain a full Common Lisp interpreter, if that is
his intent. For example, an implementation might provide a facility
called COMPRESS-FOR-DELIVERY that retains a user-specified set of root
functions and everything that they call (transitively), but that flushes
all other functions that are normally found in a Common Lisp.
If such an application happens to have an EVAL lurking within, and if
the the user somehow passes (Y-OR-N-P "Foo") to it, he might find that
Y-OR-N-P is simply undefined. Sorry, but this is a desk calculator, not
a full Common Lisp interpreter.
It seems to me that the latter approach is by far the more interesting
and useful one. It also seems to me that this is an environment issue
and not something that this committee needs to worry about. I see no
significant portability issue here. In the compressed system, EVAL
doesn't mean quite what it did before, but nobody is claiming that this
desk calculator is a legal common lisp. Exactly what COMPRESS retains
will depend on the internal details of each implementation, so there is
no point in trying to standardize this.
-- Scott
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Re: Issue: FUNCTION-TYPE (version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 15:18:19 PDT
Date: 16 Jun 87 15:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 5)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
16 Jun 87 09:07 EDT
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870616-151819-260@Xerox>
Thanks, Scott.
Given that some important members of the community don't have regular
mail access, I think it would disenfranchise them to *not* mail this
issue out. I think your rewrite looks very good. Since I'm mailing the
other issues this afternoon, I am going to release your version, intact.
I will precede it with an introduction.
∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 08:44:15 PDT
Received: from POLYCARP.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 32813; Wed 17-Jun-87 11:46:53 EDT
Date: Wed, 17 Jun 87 11:40 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617114008.1.BARMAR@POLYCARP.THINK.COM>
I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
existing code.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
barmar
∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:12:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175697; Wed 17-Jun-87 16:11:37 EDT
Date: Wed, 17 Jun 87 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: CL-Cleanup@Sail.Stanford.Edu
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617161131.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Since apparently we're going to discuss this proposal at length on the
X3J13 mailing list, I just wanted to point out one minor hole in it.
CONVERSION COST:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 15:35:51 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93095; Wed 17-Jun-87 18:15:56 EDT
Date: Wed, 17 Jun 87 18:15 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP@Sail.stanford.edu, X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870617181519.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
I'd like to state emphatically that I do not agree with this point of
view about extensions. The original point of Common Lisp was to be a
large common subset, designed to allow portable programs without
stifling extensions and experimentation, and without creating massive
compatibility problems. (I say "massive" because that's what would
happen if a policy of such explicit disallowal were applied across the
board.) If this attitude had prevailed at the beginning, there would
have been no Common Lisp.
I take the position that there ought to be tools that specifically help
you make sure that your program can be expected to run portably in other
CL implementations. The extended IF is not particularly "difficult to
detect" for such a tool; in fact, it's very easy. Meanwhile, the
extended implementation need not print out any warnings.
Such a portability tool is needed for other reasons: even if a
particular CL implementation doesn't have any "extensions", nevertheless
it necessarily makes choices about things that the CL manual leave up to
the implementation, and a program could be depending on those choices.
∂17-Jun-87 1941 edsel!bhopal!jonl@navajo.stanford.edu Issue: EVAL-DEFEATS-LINKER
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 19:41:40 PDT
Received: by navajo.stanford.edu; Wed, 17 Jun 87 19:39:01 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA00489; Wed, 17 Jun 87 19:21:41 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03068; Wed, 17 Jun 87 19:23:56 PDT
Date: Wed, 17 Jun 87 19:23:56 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706180223.AA03068@bhopal.edsel.uucp>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL.STANFORD.EDU@navajo.stanford.edu,
navajo!willc%tekchips.tek.com%RELAY.CS.NET@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Tue, 16 Jun 1987 23:39 EDT <FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Subject: Issue: EVAL-DEFEATS-LINKER
I think I'll have to agree generally with your analysis of this problem.
At Lucid, we have spent a good deal of time working on a tool similar to
what you called COMPRESS-FOR-DELIVERY, and the results are not uniformly
heartwarming. Primarly, the mass of data involved in keeping track of all
the constraints is a quagmire [that perhaps needs an expert system for
solution?]; so it is not at all as simple a task as it seems at first.
Re: We could get rid of these named functions if, by examining all the
application code, we could prove any of the following: ... [and]
Clinger's proposal is to make this proof easier by eliminating a
large class of implict symbol-to-function conversions.
I'm just as skeptical as you are about the usefulness of making a
controversial change in CL semantics just in order to remove one small
aspect of the many hurdles in front of the impossible proof. Many of
the alleged dangers of the symbol-to-function mapping are in fact
compile-time "harmless"; e.g. (mapc 'list l1 l2) should cause no one
any more concern than (mapc #'list l1 l2), so why restrict it? Also I
like to write code like
(dolist (fn '(a b c d e f))
;; Install the "boot level" versions of these basic functions
(setf (symbol-function fn)
(symbol-function (append-symbols 'boot- fn))))
Rather than throw out the baby with the bathwater, I'd much rather have a
declaration that said something like "This instance of symbol-function is
restricted to the set of symbols {a b c d e f boot-a boot-b ... boot-f}".
Somehow, if the "proof" were ever made to be successful, I fear that the
resultant language would be so much more like Pascal, and so little like
the classic Lisps that the AI world grew up on, that X3J13 might just as
well admit defeat and join the FortranADAPascalCModula crowd.
-- JonL --
∂18-Jun-87 1126 RPG FUNCTION-TYPE (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
I also believe that we should release this proposal to a larger
community. Scott's rendering of it seems good; his representation of
my position is accurate.
-rpg-
∂18-Jun-87 1132 RPG FUNCTION-TYPE (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
BARMAR's correct, we forgot to include an extension to COERCE on pages
51-52 to coerce symbols and certain lists to functions. I recall
formulating an intention to mail such a proposal, but it seems I forgot.
-rpg-
∂19-Jun-87 1429 @RELAY.CS.NET:willc@tekchips.tek.com Re: Issue: EVAL-DEFEATS-LINKER
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 19 Jun 87 14:29:06 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac22243; 19 Jun 87 16:05 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aq09203; 19 Jun 87 15:56 EDT
Received: by tektronix.TEK.COM (5.51/6.23)
id AA22564; Fri, 19 Jun 87 12:11:47 PDT
Received: by tekchips.TEK.COM (5.51/6.22)
id AA01863; Fri, 19 Jun 87 12:14:18 PDT
Message-Id: <8706191914.AA01863@tekchips.TEK.COM>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: Fahlman@C.CS.CMU.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: Issue: EVAL-DEFEATS-LINKER
In-Reply-To: Your message of Tue, 16 Jun 1987 23:39 EDT.
<FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Date: 19 Jun 87 12:14:16 PDT (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
This is my response to a message from Scott Fahlman.
> This proposal seems very odd to me.
Cultural differences account for this:
I think ordinary programs (which don't call EVAL or any of its subspecies)
should be linked selectively with no special effort. This is what people
do every day with other programming languages, including Scheme. I
couldn't care less about programs that explicitly call EVAL or its
subspecies, because Real Programmers don't call EVAL.
Scott wants programs that call EVAL or its subspecies, which he and
his culture consider to be normal programs, to be linked selectively.
This requires the user to name all the functions that might be involved
in a call to EVAL. He couldn't care less about programs that don't call
EVAL or its subspecies, because Real Programmers call EVAL.
> A normal garbage collection will keep alive all of the functions that
> are actually needed by a given application program, either directly or
> indirectly. Unfortunately, it will also keep alive every other function
> that is globally named by a symbol, even if that symbol is not mentioned
> in the application code. Such functions are still "accessible" if there
> is a read/eval present, since the user could ask for them by name, so
> the garbage collector is not allowed to eliminate them.
The second sentence is correct only if EVAL or one of its subspecies is called
explicitly, the language is poorly designed, or the implementation is not
structured for selective linking. I don't think programs that call EVAL
are worth worrying about, and I'm trying to patch the language design so
future implementatations can be designed for selective linking. Note that
READ without EVAL would cause no problems for selective linking in a well-
designed implementation if it weren't for the language problems I have
identified.
> That's one approach to eliminating the unneeded parts of Common Lisp. A
> different approach is is to simply ask the user to declare that the
> application does not contain a full Common Lisp interpreter, if that is
> his intent. For example, an implementation might provide a facility
> called COMPRESS-FOR-DELIVERY that retains a user-specified set of root
> functions and everything that they call (transitively), but that flushes
> all other functions that are normally found in a Common Lisp.
>
> If such an application happens to have an EVAL lurking within, and if
> the the user somehow passes (Y-OR-N-P "Foo") to it, he might find that
> Y-OR-N-P is simply undefined. Sorry, but this is a desk calculator, not
> a full Common Lisp interpreter.
>
> It seems to me that the latter approach is by far the more interesting
> and useful one. It also seems to me that this is an environment issue
> and not something that this committee needs to worry about. I see no
> significant portability issue here. In the compressed system, EVAL
> doesn't mean quite what it did before, but nobody is claiming that this
> desk calculator is a legal common lisp. Exactly what COMPRESS retains
> will depend on the internal details of each implementation, so there is
> no point in trying to standardize this.
>
> -- Scott
My summary of this is that Scott is proposing that the semantics of EVAL
be left unspecified, and that it is ok to do this because EVAL is part of
the programming environment, not part of the language. His proposal
wouldn't work unless we did the same for EVAL's subspecies like
SYMBOL-VALUE and SYMBOL-FUNCTION, so I have to assume he wants their
semantics to be left unspecified as well.
Considered by itself, this change in the status of EVAL and its subspecies
would be catastrophic, because essential functions like FUNCALL and APPLY
are defined in terms of EVAL or its subspecies. If we change FUNCALL and
APPLY as I propose, and go further to fix everything else that depends on
EVAL and its subspecies, then I would be very sympathetic to the idea of
dropping EVAL, SYMBOL-VALUE, and SYMBOL-FUNCTION and their ilk from the
supported language. I doubt that Scott really wants to go that far.
================================================================
I am sympathetic to David Moon's suggestion that #. and #, could be
left out of the proposal, since programs that want to be linked
selectively can just define #. and #, to be something innocuous.
-- Will
∂19-Jun-87 1737 FAHLMAN@C.CS.CMU.EDU Issue: EVAL-DEFEATS-LINKER
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Jun 87 17:37:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Jun 87 20:36:06-EDT
Date: Fri, 19 Jun 1987 20:36 EDT
Message-ID: <FAHLMAN.12311861665.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: willc%tekchips.tek.com@RELAY.CS.NET
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: EVAL-DEFEATS-LINKER
> This proposal seems very odd to me.
Cultural differences account for this:
Yeah, I guess so. I actually don't object to your proposal. I've got
no objection to your kind of "selective linking with no special effort"
if a system wants to supply it. I think that a system geared for
application delivery wants to have the kind of user-specified
compression I described in the previous note, but if some compression
can happen automatically, so much the better. If the price for this is
flushing the coercion in APPLY and FUNCALL, that just gives me another
reason to favor FUNCTION-TYPE:STRICT-REDEFINITION, which I support for
other reasons anyway. Like Moon, I dislike the change to #. and #, ,
but I guess that's not a big issue here.
My summary of this is that Scott is proposing that the semantics of EVAL
be left unspecified, and that it is ok to do this because EVAL is part of
the programming environment, not part of the language. His proposal
wouldn't work unless we did the same for EVAL's subspecies like
SYMBOL-VALUE and SYMBOL-FUNCTION, so I have to assume he wants their
semantics to be left unspecified as well.
Considered by itself, this change in the status of EVAL and its subspecies
would be catastrophic, because essential functions like FUNCALL and APPLY
are defined in terms of EVAL or its subspecies.
Well, not really. It's another matter of culture, I guess, but I think
of this as leaving the semantics of EVAL alone; EVAL still treats a
symbol defined as a function just as before. What changes is the set of
symbols that happen to have functional definitions at runtime. Think of
it as coding in a Common Lisp subset, but you don't choose the subset
until the program is done and you examine what functions you actually used.
I suppose that flushing something like ATANH at compression time could
be viewed as changing the semantics of EVAL, and I suppose you could say
that this is disastrous because EVAL is used to define other things, but
I don't really see this as a useful way to look at the world. If you
take this view, doesn't it also change EVAL (in a disastrous way) when
you define some new function?
-- Scott
∂22-Jun-87 2236 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 22:35:54 PDT
Date: 23 Jun 1987 01:34-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 5)
From: NGALL@G.BBN.COM
To: CL-Cleanup@SAIL.STANFORD.EDU
Cc: Masinter.pa@XEROX.COM
Message-ID: <[G.BBN.COM]23-Jun-87 01:34:43.NGALL>
In-Reply-To: <870616-155121-101@Xerox>
Date: 16 Jun 87 15:33 PDT
From: Masinter.pa@Xerox.COM
FUNCTION-TYPE is one of the more difficult issues facing the cleanup
committee. This is a tough but important issue that involves some
fundamental trade-offs, so discussion by the whole X3J13 committee is
called for.
My main concern about losing symbols as valid function objects (i.e.,
things that can be given to apply and funcall) is that it will make
the "functional style" of Lisp more difficult to debug.
For example, I use the following reader macro to allow function names
(symbols) to be used as arguments when my code is in the debugging
phase and "true" fucntions to be used when my code is "finished".
(defun |#!-reader| (stream subchar arg)
(declare (ignore subchar arg))
(let ((fname (read stream t nil t)))
(if *debugging-p*
`',fname
`#',fname)))
(set-dispatch-macro-character
#\#
#\!
(if *debugging-p* '|#!-reader| #'|#!-reader|))
Then, I can code the following (in most implementations):
(proclaim '(optimze (speed 0) (safety 3)))
(proclaim '(notinline froz))
(eval-when (compile load eval) (defparameter *debugging-p* t))
(defun froz ...)
...(funcall #!froz ...)...
...(mapcar #!froz ...)...
(defparameter *action-seq* `(,#!froz ,#!zorf ,#!(lambda ...) ...))
...
(apply (elt *action-seq* i) ...)
I can at any time trace froz in order to find out what is going on
(besides tracing I may also do some types of profiling). (Cf. trace,
pg 441.) And what is probably even more important, when my
observation of the behavior of froz leads me to redefine froz, every
piece of code or data-structure that references the function name froz
will correctly get the new definition.
As CLtL is currently vague as to when it is permissable to dereference
a function name to its definition (compile-time, load-time, or
apply-time), I have to avoid implementations that do not deference at
apply-time.
Under the strict redefinition proposal, I would have to recompile
every data structure that contained #'froz. In other words, it would
make functional objects impratical to debug.
Under both proposals. function names (i.e., symbols and
lambda-expressions) are (virtually) eliminated as functional objects.
This is great way to "purify" the semantics of the language, but it
puts a big burden on implementors to come up with development environments
that have the ease of debugging that function names provided.
I think I have probably mixed up a few issues here (it is late for
me), but I wanted to put in my warning that flushing function names
that can be passed around as functions has some major consequences on
Lisp style due to debugging/redefinition issues.
-- Nick
∂23-Jun-87 0809 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 08:09:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 23 Jun 87 10:57:54-EDT
Date: Tue, 23 Jun 1987 10:57 EDT
Message-ID: <FAHLMAN.12312804981.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@G.BBN.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 23 Jun 1987 01:34-EDT from NGALL at G.BBN.COM
There are lots of ways in which an implementation could provide tracing
facilities for anonymous function objects. For human-interface
purposes, function objects would be identified using some label that is
derived from the original name under which the funciton was defined.
This information could be hidden in some slot of the function object or
(somewhat more portably) associated with it in a hashtable.
I haven't thought this through, but I bet that one could develop a trace
facility like the one you describe, but using anonymous stand-in
functions that print something and then call the original function
(which can be redefined) rather than using a symbol as a wrapper. This
might even be strictly portable, which your hack is not.
If the same debugging functionality can be achieved in a different way,
I don't see the elimination of one dubious hack as a strong argument for
keeping the status quo.
-- Scott
∂23-Jun-87 0948 edsel!kent-state!eb@navajo.stanford.edu Issue: FUNCTION-TYPE (Version 5)
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 09:48:42 PDT
Received: by navajo.stanford.edu; Tue, 23 Jun 87 09:45:40 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA12003; Tue, 23 Jun 87 09:15:21 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA08001; Tue, 23 Jun 87 09:16:28 PDT
Date: Tue, 23 Jun 87 09:16:28 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706231616.AA08001@kent-state.edsel.uucp>
To: navajo!NGALL%G.BBN.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: navajo!NGALL@G.BBN.COM's message of 23 Jun 1987 01:34-EDT <[G.BBN.COM]23-Jun-87 01:34:43.NGALL>
Subject: Issue: FUNCTION-TYPE (Version 5)
Date: 23 Jun 1987 01:34-EDT
Sender: navajo!NGALL@G.BBN.COM
From: navajo!NGALL@G.BBN.COM
My main concern about losing symbols as valid function objects (i.e.,
things that can be given to apply and funcall) is that it will make
the "functional style" of Lisp more difficult to debug.
For example, I use the following reader macro to allow function names
(symbols) to be used as arguments when my code is in the debugging
phase and "true" fucntions to be used when my code is "finished".
(defun |#!-reader| (stream subchar arg)
(declare (ignore subchar arg))
(let ((fname (read stream t nil t)))
(if *debugging-p*
`',fname
`#',fname)))
(set-dispatch-macro-character
#\#
#\!
(if *debugging-p* '|#!-reader| #'|#!-reader|))
Here's a version of your debugging environment that adheres to the
strict definition of functions:
(defun |#!-reader| (stream subchar arg)
(declare (ignore subchar arg))
(let ((fname (read stream t nil t)))
(if (consp fname)
`#',fname
(if *debugging-p*
`#'(lambda (&rest x) (apply #',fname x))
`#',fname))))
(set-dispatch-macro-character
#\#
#\!
(if *debugging-p*
#'(lambda (&rest x) (apply #'|#!-reader| x))
#'|#!-reader|))
∂23-Jun-87 1145 NGALL@G.BBN.COM Re: Issue: FUNCTION-TYPE (Version 5)
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 23 Jun 87 11:44:55 PDT
Date: 23 Jun 1987 14:43-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 5)
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]23-Jun-87 14:43:05.NGALL>
In-Reply-To: <FAHLMAN.12312804981.BABYL@C.CS.CMU.EDU>
Date: Tue, 23 Jun 1987 10:57 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
...
I haven't thought this through, but I bet that one could develop a trace
facility like the one you describe, but using anonymous stand-in
functions that print something and then call the original function
(which can be redefined) rather than using a symbol as a wrapper. This
might even be strictly portable, which your hack is not.
That's the problem. No implementations (except perhaps Symbolics)
seem to have thought through encapsulation issues (of which tracing is
but one example). Thus in many implementations, tracing functions
called from compiled code, even with speed 0 and safety 3 and
notinlines, does not work, or only works in some situtations.
If the same debugging functionality can be achieved in a different way,
I don't see the elimination of one dubious hack as a strong argument for
keeping the status quo.
That's a big IF in my opinion, given that most implementations have so
far only provided the crudest of tracing and breaking facilities
(which all depend on apply-time deferencing of function-names).
It is not entirely clear from your response what you consider to be my
dubious hack. If you mean that depending on implementations to
dereference function-names (i.e., symbols) at apply time (unless
declarations permit otherwise), then I must disagree with you.
Virtually all Lisp interpreters have this behavior, it is the
compilers that cause inconsistent behavior. And since one of Common
Lisp's major goals is to "impose identical semantics" on compiled and
interpreted code, I claim that my examples were perfectly correct CL
programs and compilers that don't enforce proper dereferencing are
broken.
The ability to apply function names (and have them deferenced as late
as possible) may have gotten into Lisp for
dubious reasons, but it has been a very strong reason why Lisp has
succeeded as a flexible, incremental, and rapid development
environment. If we remove this feature without alternative mechanisms
ALREADY IN PLACE, we will make Lisp debugging more primitive than
conventional language debugging.
-- Nick
∂23-Jun-87 1538 RAM@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 15:38:19 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 23 Jun 87 18:37:27-EDT
Date: Tue, 23 Jun 1987 18:37 EDT
Message-ID: <RAM.12312888633.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: NGALL@G.BBN.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Fahlman@C.CS.CMU.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 23 Jun 1987 14:43-EDT from NGALL at G.BBN.COM
Since this message addresses compiler semantics, I thought I'd comment
on it...
Date: Tuesday, 23 June 1987 14:43-EDT
From: NGALL at G.BBN.COM
To: Fahlman at C.CS.CMU.EDU
Re: Issue: FUNCTION-TYPE (Version 5)
[...] It is not entirely clear from your response what you
consider to be my dubious hack. If you mean that depending on
implementations to dereference function-names (i.e., symbols) at
apply time (unless declarations permit otherwise), then I must
disagree with you. Virtually all Lisp interpreters have this
behavior, it is the compilers that cause inconsistent behavior.
And since one of Common Lisp's major goals is to "impose identical
semantics" on compiled and interpreted code, I claim that my
examples were perfectly correct CL programs and compilers that
don't enforce proper dereferencing are broken.
Perhaps unfortunately, it isn't possible to implement anything that
could reasonably be called a "compiler" so that it has exactly the
same semantics as traditional interpreters. The entire purpose of a
compiler is to make use of compile-time information in order to
transform the program into a more efficient and more specific program.
In my compiler cleanup proposal, I argue that Common Lisp shouldn't
talk about the semantics of compiled v.s. interpreted code, instead it
should define "evaluation" in a way that is broad enough to encompass
both compiled and interpreted evaluation strategies. This mostly
amounts to saying "It is an error to write a program that cannot be
compiled.", since there are few things a compiler can do that
interpreters don't.
The ability to apply function names (and have them deferenced as
late as possible) may have gotten into Lisp for dubious reasons,
but it has been a very strong reason why Lisp has succeeded as a
flexible, incremental, and rapid development environment.
This is a valid point, but it doesn't directly translate into marching
orders for Common Lisp standardization. We should attempt to design
Common Lisp so that it doesn't preclude useful environment features,
but we are not obligated to provide them directly in the language.
I agree with you that it should be possible to force compilers to do
full function call, but the issues aren't totally clear. For example,
the functions that are being expanded inline are presumably standard
Common Lisp functions. It is all very well to say "NOTINLINE inhibits
inline expansion", but this capability is of little use unless you can
redefine standard functions. [Which was discussed to death on
common-lisp a while back.]
You must always remember that when Common Lisp says that something "is
an error", implementations are not forbidden to assign meaning to that
usage. If there is a feature that is needed to support an environment
so amazing mind-bogglingly whizzy that you can't live without it, then
everybody will want that kind of environment support, and all
"reasonable" implementations will provide it. This in itself is not a
particularly strong argument for standardizing the *feature that
supports the environment*. It is only when we start talking about
portable environment facilities that we become concerned.
The concept of a "reasonable" implementation is also important.
Common Lisp does not reqire implementations to be reasonable; it only
requires that programs meeting the specification run in all
implementations (subject to resource limitations and other ill-defined
vaguenesses.) It is not a valid argument to say "X must be in Common
Lisp because I refuse to use a system that doesn't support X." You
must demonstrate that X aids significantly in writing interesting
portable programs, rather than simply allowing you to hack in the
manner to which you have become accustomed.
Rob
∂25-Jun-87 2333 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE: not allowing symbols to be used as functions
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jun 87 23:33:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182745; Fri 26-Jun-87 01:43:35 EDT
Date: Fri, 26 Jun 87 01:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE: not allowing symbols to be used as functions
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870626014327.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
*MACROEXPAND-HOOK* is another one you overlooked. Its default value
is the symbol FUNCALL, and its value gets funcalled, therefore it
relies on funcalling a symbol and would need to be reworked.
∂26-Jun-87 1104 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Issue: IF-BODY (Version 7)
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 26 Jun 87 11:04:33 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 26 Jun 87 13:02:58-CDT
Date: Fri, 26 Jun 87 13:02 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP%Sail.stanford.edu@MCC.COM
cc: Masinter.pa%Xerox.COM@MCC.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870626130230.6.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
If I were to change IF to allow multiple else causes I would like to
change IF to be like Bernie Greenberg's IF in his Multics Emacs
implementation, namely:
(IF test then-clauses :ELSE else-clauses)
This certainly would be incompatible with existing code but would allow
both multiple THEN and ELSE clauses.
-- David D. Loeffler
∂29-Jun-87 2239 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR-DOCUMENTATION (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jun 87 22:39:09 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 185077; Tue 30-Jun-87 01:27:05 EDT
Date: Tue, 30 Jun 87 01:26 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFVAR-DOCUMENTATION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870630012646.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DEFVAR-DOCUMENTATION
References: DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category: CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is not explicit about whether the documentation part of
DEFVAR, DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
Clarify that the documentation part of DEFVAR, DEFPARAMETER, and
DEFCONSTANT special forms is not evaluated. That is, it must be
a literal string, not a form which evaluates to a string.
Rationale:
To ensure portability, implementations must agree on whether or not
this position is evaluated. Specifying that the position is unevaluated
is the conservative thing to suggest.
Current Practice:
Some implementations evaluate this position. Others do not.
Adoption Cost:
The change is presumably trivial in all implementations.
Benefits:
Code portability would be improved.
Conversion Cost:
Code which uses other than a literal string is not portable, so no portable
programs will be broken. Some non-portable programs which rely on a particular
vendor's interpretation would have to be rewritten. Automatic tools to detect
most offending cases could trivially be constructed.
Aesthetics:
No significant impact.
Discussion:
Pitman thinks this is a good idea.
∂06-Jul-87 1658 Masinter.pa@Xerox.COM AREF-1D (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jul 87 16:57:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUL 87 16:45:33 PDT
Date: 6 Jul 87 16:45 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 6)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870706-164533-1986@Xerox>
This revision clarifies the proposal by giving arguments and some
equivalence relations. I added that row-major-aref was usable with SETF
(which did not appear in the original proposal although it was implied
in one of the examples.)
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
6-Jul-87, Version 6, by Masinter
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
row-major-aref array index [Function]
This accesses and returns the element of array specified by index when
the elements of array are considered in row-major order. Array may be an
array of any dimensionality. row-major-aref may be used with setf. For
reference, the following sets of expressions are equivalent:
(row-major-aref array index) ==
(aref (make-array (array-total-size array)
:displaced-to array
:element-type (array-element-type array))
index)
and
(aref array .. subscripts ..) ==
(row-major-aref array (array-row-major-index array .. subscripts
..))
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something to which they already
have inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee generally supports this enhancement. Version 2 was
endorsed (assuming change to function name ROW-MAJOR-AREF.)
----- End Forwarded Messages -----
∂13-Jul-87 1257 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 12:54:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870713-125407-2098@Xerox>
We are tasked with producing a new version of FUNCTION-TYPE for
consideration at the next X3J13. The new version should reflect the
discussion held so far. My notes and memory are poor. Does anyone else
have any notes?
My notes include that point 6 (the description of COMPILE) should be
removed from this proposal, that there was some sentiment for
considering a proposal where symbols coerced to their symbol-function
but lists did not, consideration of APPLICABLE-P, a proposal where
FUNCTION and FUNCTIONP stayed the same but there was a new type
PROCEDURE and PROCEDUREP, that we be more consistent about justifying
removing COMPILED-FUNCTION-P (i.e., why bother?), that the proposal
mention selective linking.
Some of the discussion centered around the merits of Dynamic Linking and
the Value of Lisp, the behavior of COERCE and the FUNCTION type.
∂13-Jul-87 1321 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 13:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 13:18:40 PDT
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870713-131840-2151@Xerox>
This issue passed conditionally. In this version, I changed the last
paragraph of the proposal, and attempted to add a test case. I hope
that I did not spoil the intent.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global
SETF definitions of the name defined by the MACROLET, FLET or LABELS do
not apply. A SETF method applies only when the global function binding
of the name is lexically visible. All of the built in macros of Common
Lisp (SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location
specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro
expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂13-Jul-87 1344 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 13:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 13:18:40 PDT
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870713-131840-2151@Xerox>
This issue passed conditionally. In this version, I changed the last
paragraph of the proposal, and attempted to add a test case. I hope
that I did not spoil the intent.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global
SETF definitions of the name defined by the MACROLET, FLET or LABELS do
not apply. A SETF method applies only when the global function binding
of the name is lexically visible. All of the built in macros of Common
Lisp (SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location
specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro
expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂13-Jul-87 1415 Masinter.pa@Xerox.COM Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 14:15:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 14:11:08 PDT
Date: 13 Jul 87 14:05 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Status
Message-ID: <870713-141108-2238@Xerox>
This is my status file.
Please reply with individual messages about each issue.
At the face-to-face meeting before X3J13, we discussed the remaining
issues in Clarifications.txt. I will be sending out separate messages
about each of those under the heading of an issue name I will ascribe,
and will then add those issues to the status file.
I intend to segment this status file into Active, Passed and Tabled
Indefinitely. (I suppose there might be some argument about dividing
things between Active and Tabled, but I urge you to avoid arguing about
it until there's an issue that I've marked Tabled that you want to
continue to discuss.)
!
Proposal format (Version 11)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
(Suggestion to add a Related Issues field.)
ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Masinter to revise, clarify :displaced-to ommitted'
same as :displaced-to nil.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
Notes from boston cl-cleanup meeting have *, but
the mail traffic seems inconclusive.
* AREF-1D (Version 6/6 JUL 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 released
Conditionally passed at X3j13/Jun87 pending new version.
Version 6 mailed to cl-cleanup.
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Not ready for release.
Needs revision of current practice, test case, example. (KMP?)
The summary says Version 2, but I only have version 1 on file.
Does anyone else have a version 2? Or was this wishful thinking?
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
Postponed pending error proposal
< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87.
< DEFVAR-INITIALIZATION (Version 4/Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13/Jun87.
< DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Not ready for release.
Needs more information on implementation and
performance cost.
Masinter will rewrite, flush :ALLOWED option,
rewrite :ADD-KEYWORDS to make default for
:ALLOW-DUPLICATES as NIL., conversion cost => nil.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Not ready for release.
Was discussion at X3J13 conclusive?
Should this issue be abandoned? (cc: clinger, please)
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Defer to condition system?
In discussion, formal proposal not yet submitted.
< FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
< FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 4 passed X3J13/Jun87.
FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
Ready for release.
FORMAT-NEGATIVE-PARAMETERS
In discussion, formal proposal not yet submitted.
Notes: is this an editorial policy question rather than
an individual issue?
< FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
Discussed at X3J13, new proposal due.
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
Pitman volunteered to revise.
* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 mailed 13-Jul-87 13:18:47
IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
Discussed at X3J13/Jun 87.
Postpone pending resolution of policy on extensions?
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
(Was not released).
< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Examine wording and avoid "keyword argument" phrasing.
Introduce phrase "a key argument" to denote arguments
defined with &KEY ??
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release.
Deferred to compiler committee?
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
Masinter will extract from environment-arguments
* PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Needs revision to clarify "file" = "opened with open"
(there are some non-file devices which have pathnames)
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
Moon will revise, extend language, clarify
which functions are affected, etc.
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release.
Pitman will revise & resubmit.
< PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
Rees & Moon will revise & resubmit. Rees says he won't.
David?
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release.
Tabled indefinitely.
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
In discussion, formal proposal not yet submitted.
Need volunteer to submit.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, formal proposal not yet submitted.
Table indefinitely.
REMF-DESTRUCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release.
Pitman will revise & resubmit.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release.
Pitman will revise & resubmit.
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Not ready for release.
Forward to Linden for character proposal?
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Not ready for release.
Pitman will revise & resubmit.
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
Not ready for release.
Pitman will revise & resubmit.
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
Send to macro committee?
TAILP-NIL
(Operation of TAILP given NIL)
Not ready for release.
Masinter will revise & resubmit.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
Gabriel will revise & resubmit.
∂15-Jul-87 1329 Masinter.pa@Xerox.COM Issue: Pathname-subdirectory-list
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jul 87 13:29:01 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 15 JUL 87 13:27:05 PDT
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: Pathname-subdirectory-list
To: cl-cleanup@sail.stanford.edu
cc: Ghenis.pasa@Xerox.COM
Message-ID: <870715-132705-3165@Xerox>
This arrived in my mailbox before the X3J13 meeting. While I suspect
there may be some alternative proposals, and perhaps some other
important related issues, this seems like a good way to introduce the
topic.
!
ISSUE: (PATHNAME-SUBDIRECTORY-LIST)
REFERENCES: CLtL pages 409 - 418
CATEGORY: ADDITION
EDIT HISTORY: Version 1 by Ghenis.pasa@Xerox.com, 06/18/87
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW):
Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.
The string form of a pathname can be obtained by using the appropriate
OS-specific separator and end-delimiters.
Require global variables called LISP:*HOST-OS-ALIST* and
LISP:*DEFAULT-OS* to provide the information needed to assemble
namestrings correctly
TEST CASE (desired behavior):
>(defparameter LISP:*HOST-OS-ALIST*
'(("vmsvax" . "vms") ("unixvax" . "unix"))
>(defparameter LISP:*DEFAULT-OS* "msdos")
>(defvar vmspath
(make-pathname :host "vmsvax"
:directory "smith"
:sudirectories '("lisp")
:name "test"
:type "lsp"))
>(defvar localpath
(make-pathname :directory "smith"
:sudirectories '("lisp")
:name "test"
:type "lsp"))
>(namestring vmspath)
"{vmsvax}[smith.lisp]test.lsp"
>(namestring localpath)
"c:\smith\lisp\test.lsp"
RATIONALE:
Pathnames are an abstraction meant to deal with the common notions in
file systems. Subdirectories exist in most operating systems. Common
Lisp must provide a standard way of dealing with subdirectories for
pathnames to be truly useful.
CURRENT PRACTICE:
CLtL acknowledges this problem and declares it to be a system dependent
issue.
ADOPTION COST:
This should be a simple addition to implement.
BENEFITS:
Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent. Relative pathnames could be trivially
specified by pathnames lacking a :DIRECTORY field.
CONVERSION COST: This is an upwards-compatible addition.
AESTHETICS:
Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent.
DISCUSSION: >>Additional arguments, discussions, endorsements,
testimonials, etc. should go here.<<
∂16-Jul-87 1714 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: Pathname-subdirectory-list
Received: from [192.10.41.144] by SAIL.STANFORD.EDU with TCP; 16 Jul 87 17:14:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194405; Thu 16-Jul-87 20:14:29 EDT
Date: Thu, 16 Jul 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa@Xerox.COM, Ghenis.pasa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870715-132705-3165@Xerox>
Message-ID: <870716201416.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
I agree with the problem description. We've been dealing with heterogeneous
network for quite some time and have run into the same thing.
PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW):
Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.
Adding a new field as a way of solving this problem doesn't make sense.
Subdirectories are a structuring of the existing directory field, they are
not a new -independent- aspect of a pathname.
The solution to this problem that Symbolics has used for years works
quite well. The directory is a structured field whose value is returned
as a list of strings, one string for each subdirectory level. In
addition to strings, in our system we allow certain keywords in the
list, enumerated below. Note that this general approach is the solution
suggested by CLtL itself, page 412 about 3/4 of the way down the page;
thus the only reason to change the language would be if we want to force
all implementations to use the same representation of structured
directories, which might be difficult if some implementation uses a
strange file system with a directory feature we haven't thought of.
When constructing a pathname, either a list of strings, or a single
string containing host-dependent delimiters, is accepted. To retrieve a
string containing host-dependent delimiters, the existing
DIRECTORY-NAMESTRING function is used.
In case those keywords aren't self-evident, here are some examples.
Vixen is a Unix, presumably everyone is familiar with Unix pathname
syntax.
(make-pathname :host "vixen"
:directory '("foo" "bar")) => #P"VIXEN:/foo/bar/"
(make-pathname :host "vixen"
:directory '(:relative "bar")) => #P"VIXEN:bar/"
(make-pathname :host "vixen"
:directory '(:relative :up "bar")) => #P"VIXEN:../bar/"
(make-pathname :host "vixen"
:directory '(:relative :up :up "bar")) => #P"VIXEN:../../bar/"
(make-pathname :host "vixen"
:directory '("foo" :wild "bar")) => #P"VIXEN:/foo/*/bar/"
I can't show you :wild-inferiors on Unix, because Unix is too simple
and elegant to have such useful features, so I'll use VMS:
(make-pathname :host "dumbo"
:directory '("foo" :wild "bar")) => #P"DUMBO:[foo.*.bar]"
(make-pathname :host "dumbo"
:directory '("foo" :wild-inferiors "bar")) => #P"DUMBO:[foo...bar]"
The name of the VMS host is not intended to be particularly pejorative, all of our
Vaxes are named after flying critters.
∂16-Jul-87 1730 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from [192.10.41.144] by SAIL.STANFORD.EDU with TCP; 16 Jul 87 17:27:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194407; Thu 16-Jul-87 20:19:38 EDT
Date: Thu, 16 Jul 87 20:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870713-131840-2151@Xerox>
Message-ID: <870716201931.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
This issue passed conditionally. In this version, I changed the last
paragraph of the proposal, and attempted to add a test case. I hope
that I did not spoil the intent.
The new version looks okay to me.
∂20-Jul-87 2130 edsel!bhopal!jonl@labrea.stanford.edu Apropos case sensitive?
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:30:44 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:26:35 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05223; Fri, 17 Jul 87 11:45:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00220; Fri, 17 Jul 87 11:49:11 PDT
Date: Fri, 17 Jul 87 11:49:11 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171849.AA00220@bhopal.edsel.uucp>
To: labrea!vrotney%venera.isi.edu@labrea.stanford.edu
Cc: labrea!Common-Lisp%sail@labrea.stanford.edu,
labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: vrotney@venera.isi.edu's message of Tue, 14 Jul 87 19:45:12 PDT <8707150245.AA03095@hpai00>
Subject: Apropos case sensitive?
[Note: LUCIDites are now using another mail gateway: typical address is:
edsel!jonl@labrea.stanford.edu]
Our reasoning here at Lucid was similar to what you came up with -- namely
that the language of CLtL, p. 443, very strongly implied the same semantics
of macthing as the default for SEARCH, which is an EQL, rather than an
EQUALP, test.
Many of us also felt the need so strongly for a case-insensitive apropos
that Lucid Common Lisp actually has two such functions hidden inside it:
lucid::case-insensitive-apropos
lucid::case-insensitive-apropos-list
but they will probably be "shaken" out in the delivered 2.1 beta images.
I feel that this issue should be presented to the "cleanup" sub-committee
of the X3J13 standards committee. Perhaps SEF can prod Steve Handerson
into writing up a proposal to them? Lucid might feel impelled to "expose"
this hidden function if the committe were inclined towards the proposal.
By the way, there are some other issues about apropos that might need
"cleaning up", some of which were discussed on this list a couple of
years ago (for "couple" mabye equal to one). For example, the
documentation uses the term "available symbols", but in at least one
instance, it ought to use "accessible symbols", for conformity to
chapter 11 on packages. Also, the scope of do-all-symbols has been
questioned by some; there have been at least two proposals on it:
(1) to add a new "function" called, say do-most-symbols, that excluded
certain packages
(2) to add a global variable (or a special variable) called, say,
*all-symbols-exclusions* which is a list of packages which the
several "all-symbols" functions would skip [e.g., do-all-symbols,
find-all-symbols, apropos, case-insensitive-apropos, etc]
-- JonL --
∂23-Jul-87 1735 Masinter.pa@Xerox.COM Issue: LOAD-TIME-EVAL (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 87 15:50:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 87 15:50:14 PDT
Date: 23 Jul 87 15:49 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
Subject: Issue: LOAD-TIME-EVAL (Version 2)
Message-ID: <870723-155014-1175@Xerox>
The following from Jim Kempf:
Larry:
I've modified the proposal for LOAD-TIME-EVAL along the lines
suggested by Dave Moon and am resubmitting it. I'll keep the name of
the proposal at LOAD-TIME-EVAL, although LOAD-TIME-CONSTANT, as suggested
by Dave is probably a more appropriate name. SHARP-COMMA-SPECIAL-FORM
seems pretty much to be out, since the new proposal is for a functional
interface, rather than a special form.
Note that Dave's proposal will require more extensive modifications
in our system than a macro or special form; however, I believe it is
more elegant, since it avoids introducing a new special form (one of
the original goals of Common Lisp), and therefore more appropriate.
Jim Kempf kempf@hplabs.hp.com
!
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: Version 2 submitted 7/17/87, James Kempf.
Problem description:
The specification of #, (load time evaluation) in Common Lisp provides
a means, during compilation, of arranging for the evaluation of a
quoted or (in some implementations) unquoted form within embedded forms
processed by the reader, when the compiled file is loaded.
Inhibition of processing when a file is loaded into the interpreter
is possible using (EVAL-WHEN (LOAD) ... ). Code which is returned
during macroexpansion, however, is not processed by the reader, so
there is no way to arrange for deferral of processing until compiled
file load time in macroexpanded code.
Proposal (LOAD-TIME-EVAL:MAKE-LOAD-TIME-EVAL):
(MAKE-LOAD-TIME-EVAL <quoted form> &ENVIRONMENT env) : function
When processed by the interpreter or when encountered during evaluation
of the COMPILE function, the <quoted form> is evaluated once (and only
once) and the result is returned. When processed during a file
compilation, arrangement is made for the <quoted form> to be
evaluated when the compiled file is loaded, and the result returned.
Note that determining when file compilation is occurring and the details
of arranging for deferral of further processing until compiled
file load time are necessarily implementation dependent.
Test Case:
(defmacro print-load-date (&environment env)
`(quote ,(make-load-time-eval '(format T "~A~%" (get-date) env))))
When interpreted or processed during invocation of COMPILE, this
macro expands into code which prints the return value of the GET-DATE
function (presumed, for purposes of this example, to be a human
readable date) to *STANDARD-OUTPUT*. When macroexpanded during a
file compilation, printing is deferred until the compiled file is
loaded.
Rationale:
Currently, there is no portable way to arrange for code returned
from a macro to defer evaluation until load time.
Current practice:
Currently, every version of Common Lisp is required to implement
compiler hooks for #, but, since this is only recognized by
reader, there is no portable way to achieve the same effect. Users
of Portable CommonLoops are encouraged to implement something similar.
Adoption Cost:
The cost to implementors will depend on how #, is implemented.
In some implementations, the primitives for implementing
MAKE-LOAD-TIME-EVAL may already exist, in others, more substantial
changes may be required.
Cost of non-adoption:
There are numerous possible uses for this facility. Version control
and system building facilities (such as the example) and optimization
of method invocation in the Common Lisp Object System come immediately
to mind. While every implementation of Common Lisp could certainly
provide an implementation specific facility, portability would suffer.
Benefits:
Portability. May make extensions to the Common Lisp Object system
via. the metaobject protocol easier.
Conversion Cost:
Most applications developers should not see much difference.
Esthetics:
The proposal fills a hole in the spectrum of alternatives for deferring
evaluation until a compiled file is loaded. Currently, code which is
read by the reader can arrange for it to be done, as can top level code,
but embedded code cannot.
Discussion:
There is likely to be some controversy about this proposal, since
there is no universally agreed upon formal processing model for
Common Lisp, but only a set of informal rules and various implementations.
Those implementations which have the primitives available should be
able to implement MAKE-LOAD-TIME-EVAL with little change to their
kernels, those which don't may require more extensive modifications.
∂23-Jul-87 1735 Masinter.pa@Xerox.COM Status, clarification list, members
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 87 15:54:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 87 15:54:24 PDT
Date: 23 Jul 87 15:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Status, clarification list, members
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870723-155424-1184@Xerox>
First, I want to apologize again for the delay in getting out the list
of clarifications & issues. I feel like it is important to merge in the
discussion with the work Scott Fahlman did in January of this year. I'm
still working on this list.
I've added Dieter Kolb, Siemens, Germany to the distribution list.
Siemens has a mail connection to Xerox, and Dieter can get arpanet mail
addressed to cl-cleanup, but, due to some technical and administrative
problems, I will have to forward his mail to the distribution list.
I will be adding another EuLisp committee member to cl-cleanup as well.
Part of our goal is to make sure that the EuLisp community is well
represented in the cleanup process.
∂24-Jul-87 1024 KMP@STONY-BROOK.SCRC.Symbolics.COM OPEN-KEYWORDS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:24:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198555; Fri 24-Jul-87 13:25:34 EDT
Date: Fri, 24 Jul 87 13:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: OPEN-KEYWORDS
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870724132524.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: OPEN-KEYWORDS
References: Pages 420-422
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 07/17/87
Problem Description:
The :if-exists and :if-does-not-exist arguments interact, but keyword
arguments should generally be orthogonal.
Proposal (OPEN-KEYWORDS:ORTHOGONAL):
Delete the following phrases from the first 2 paragraphs on page 422:
", or if the :if-exists argument is :overwrite or :append" and
", and the if-exists argument is anything but :overwrite or :append"
Test Case:
The following piece of code causes an error to be signaled:
(open "test" :direction :output :if-exists :overwrite)
if a file named "test" -doesn't- already exist.
With the change in this proposal, it wouldn't be an error.
Rationale:
As is clear from the test case example, a user might want to specify
that a certain action get taken in the case that a file already
exists, without affecting what happens in the case that it doesn't
exist. There is no good reason for the two cases to affect each
other.
Current Practice:
Adoption Cost:
Slight.
Benefits:
More sensible, easier to understand, more efficient to use and to
implement.
Conversion Cost:
Slight, automatable.
Esthetics:
Keyword arguments are supposed to be orthogonal, thus this deviation
is unaesthetic. It being so contrary to intuition makes it particularly
difficult for new LISP users to grasp.
Discussion:
∂24-Jul-87 1038 KMP@STONY-BROOK.SCRC.Symbolics.COM Mail from Skona Brittain
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:38:35 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198567; Fri 24-Jul-87 13:39:24 EDT
Date: Fri, 24 Jul 87 13:39 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Mail from Skona Brittain
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870724133919.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The OPEN-KEYWORDS proposal which I just sent arrived in my hardcopy mailbox
today. I passed it through completely unedited; in fact, I didn't have time
to read it while I was typing. I'll comment later when I've had time.
There was also a cover letter that said:
... I still have not been able to do much of anything with my account.
I tried to send mail but kept getting "no such local user" messages,
even when just directly responding to a test message from a non-local
friend. Nor have i received any X3-J13 mail at all yet. So if you want
to respond to this, I would appreciate your trying my netmail address,
but if your mail gets returned, please use [P.O. Box 747, Santa Barbara,
CA 93102; (805) 963-3412].
Regarding the order of arguments' evaluation, as in the
push-evaluation-order proposal, I still believe that this is specified in
CLtL. I mentioned the reference on page 97 to "the usual left-to-right
order in which the various subforms are evaluated" but have since found
a less oblique one: the entire last half of page 99.
It is my impression that there needs to be a clarification of the
effect of *print-level* and *print-length*, so if this impression is
correct, I will volunteer to write it up. Basically, there seems to be a
confusion about whether it is the actual components of the object that
count or what the object looks like when printed in list notation. For
example, the levels of 'x and (quote x) are considered different (cf
page 373) but string-char arrays of rank >1 are affected by
*print-length* even when printed in non-list notation (cf page 369).
Other cases that are affected by this distinction include
- a structure with n components has 2n+1 elements in its printed list
representation
- nil vs. ()
- a rank 0 array has a component but prints with no parentheses whereas
a 0xN array has 2 levels of parens and no components, etc.
Since I am obviously not as well-qualified as the rest of the
clean-up committee to judge such issues, and since I don't have access
to any other preliminary feedback, there does not seem to be much point
in my proceeding with writing up something like this until further
notice.
A suggestion for a change that I have is that some of the defstruct
arguments be strings instead of symbols, but I also don't know if
there's any point in entertaining it.
I was under the impression at the meeting Monday that thecleanu-up
committee was going to suggest setting up several other committees,
including one on the file systems handling, but when I reminded Larry on
Wednesday, he said there weren't any that hadn't already been set up, so
I am unsure of the status of the situation regarding a file
subcommittee. ...
∂27-Jul-87 1005 KMP@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 87 10:05:12 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 199647; Mon 27-Jul-87 13:02:54 EDT
Date: Mon, 27 Jul 87 13:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870727130240.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of
what happens if an argument to APPEND is a dotted list.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last list given to
append is discarded (whether NIL or not) when constructing the new list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are
the same, since these two might legitimately differ in situations involving
dotted lists. As such, deciding which to use is not just a stylistic issue.
Test Case:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
[Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).]
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number
of implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter).
Adoption Cost:
Technically, the change should be relatively small for those
implementations which don't already implement it. However:
If there are any implementations which have microcoded APPEND incompatibly,
the small change may nevertheless be somewhat painful.
Some implementations may have optimized their APPEND to expect only NIL
when SAFETY is 0. In this case, depending on implementation details,
requiring an ATOM check rather than a NULL check may slow things down.
Benefits:
Since non-lists are allowed as a last argument and since APPEND can
therefore produce dotted lists, some readers may have (incorrectly)
assumed that APPEND can reliably deal in general with dotted lists,
something that doesn't appear to be guaranteed by a strict reading. The
proposed extension would happen to legitimize such assumptions.
Conversion Cost:
This change is "upward compatible".
Aesthetics:
Whether or not users will think this improves the aesthetics of the
language will depend largely on how they view the relation between
lists and dotted lists. Those who view dotted lists as a special kind
of list may feel differently than those who view lists as a special
kind of dotted list.
Discussion:
KMP supports the proposed extension.
∂27-Jul-87 1754 FAHLMAN@C.CS.CMU.EDU APPEND-DOTTED
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87 17:54:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jul 87 20:54:00-EDT
Date: Mon, 27 Jul 1987 20:53 EDT
Message-ID: <FAHLMAN.12321826393.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: APPEND-DOTTED
In-reply-to: Msg of 27 Jul 1987 13:02-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
This looks good to me.
-- Scott
∂27-Jul-87 1802 FAHLMAN@C.CS.CMU.EDU [Fahlman: Iteration standard]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87 18:02:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jul 87 21:02:34-EDT
Date: Mon, 27 Jul 1987 21:02 EDT
Message-ID: <FAHLMAN.12321827954.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Fahlman: Iteration standard]
This is not really cleanup committee business. I just thought that it
might be of interest to some of you...
Date: Thursday, 23 July 1987 21:15-EDT
From: Scott E. Fahlman <Fahlman>
To: loop-groop%clam at SUN.COM
cc: fahlman
Re: Iteration standard
OK, apparently this is the proper address for iteration discussions.
Here's what I wanted to say (probably an anticlimax at this point):
In the past, I have always been a vocal opponent of adopting the MIT
LOOP macro, or anything very close to it, as a part of the Common Lisp
standard. I think that the basic functionality of LOOP is OK, and I've
got no real problem with its lack of a clean unifying abstraction; my
objection was that the cute, non-Lispy, pseudo-English infix/keyword
syntax was confusing and not in keeping with the rest of the language or
the direction in which Lisp should be moving. My hope was that if we
stalled this decision for a while, someone would come up with something
better and that that "something better" would catch on in some
significant segment of the community. (This strategy turned out to be a
good one with respect to object-oriented programming and old-style
flavors.)
Well, I've mellowed on this. Personally, I would still rather see
something like
(loop (for i 0 100 2)
(while (non-prime-p (foobar i))
(collect (flowers-in-may))
(finally (print *famous-last-words*)))
than the non-parenthesized run-on sentence equivalent, but we've been
hung up on this difference of opinion for five years and I'm ready to
throw in the towel. Nothing else has caught on, and in the meantime
LOOP has consolidated its position and started to spread. It IS better
than nothing. The people who use it seem to like it. When
pretty-printed properly it is readable enough -- I can blur my eyes and
pretend that the missing parens are there.
So, speaking only for myself, I would be willing to accept and even
support LOOP or something very similar as long as (1) it is cleanly
defined and (2) someone provides a portable, efficient public-domain
implementation. In my view, it's time to settle this and move on.
Of course, I can't speak for the other people who still find LOOP syntax
disgusting. Maybe some of the others are ready to compromise as well.
I was discussing this with Stan Shebs of Utah -- another former LOOPS
hater, probably because he was a fan of PSL's FOR macro -- and he was
also ready to bow to the inevitable. Those who favor a more uniform and
principled approach to the whole iteration business -- the fans of LetS,
for example -- may be harder to please.
-- Scott
∂30-Jul-87 1129 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 87 11:28:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202848; Thu 30-Jul-87 14:29:55 EDT
Date: Thu, 30 Jul 87 14:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <870713-141108-2238@Xerox>
Message-ID: <870730142947.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 Jul 87 14:05 PDT
From: Masinter.pa@Xerox.COM
* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
( &KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Examine wording and avoid "keyword argument" phrasing.
Introduce phrase "a key argument" to denote arguments
defined with &KEY ??
In some CLOS stuff I'm writing today, I'm using the terms "positional
argument" and "named argument". Positional arguments are received by
required and optional parameters, while named arguments are received
by &key parameters. &rest parameters can receive either kind of argument.
I don't have time to revise the proposal today, but perhaps I can do
so along these lines later, if people agree that this is a good
terminology.
∂30-Jul-87 1145 FAHLMAN@C.CS.CMU.EDU Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 87 11:44:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jul 87 14:44:49-EDT
Date: Thu, 30 Jul 1987 14:44 EDT
Message-ID: <FAHLMAN.12322545615.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
In-reply-to: Msg of 30 Jul 1987 14:29-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Seems like a good terminology to me, though you'll have to define your
terms at the start of the proposal so that nobody has to guess exactly
what you mean.
-- Scott
∂30-Jul-87 1717 Masinter.pa@Xerox.COM Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 87 17:16:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 87 17:16:56 PDT
Date: 30 Jul 87 17:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 30 Jul 87 14:29 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870730-171656-1501@Xerox>
While I think that "positional" and "named" are good ways of talking
about the different kinds of arguments, and that "key arguments" is
awkward, I don't think it is necessary for you to spend your time
rewriting the proposal KEYWORD-ARGUMENT-NAME-PACKAGE, which doesn't
make any recommendations about terminology in the standard; rather, it
just uses it locally.
I would like to see a set of "terminology" recommendations for the spec
gathered and passed by X3J13; there are a number of other things which
have passed through here that would belong in it. I don't think they fit
into the standard form for language changes (since the considerations
are different, e.g., "current practice" might refer to existing
textbooks and programming language literature).
∂31-Jul-87 1833 edsel!bhopal!jonl@labrea.stanford.edu Issue KEYWORD-ARGUMENT-NAME-PACKAGE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 18:33:28 PDT
Received: by labrea.stanford.edu; Fri, 31 Jul 87 18:22:00 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA04329; Fri, 31 Jul 87 18:22:15 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA06397; Fri, 31 Jul 87 18:19:33 PDT
Date: Fri, 31 Jul 87 18:19:33 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708010119.AA06397@bhopal.edsel.uucp>
To: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 30 Jul 87 14:29 EDT <870730142947.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
I too like this terminology, and think that changing it now is an important
thing to do, despite the five years of "keyword arguments."
By the way, as an English phrase, "&key parameters" leaves me a bit cold.
How about "positional parameters" and "named parameters" , to parallel
"positional arguments" and "named arguments"?
-- JonL --
∂05-Aug-87 1931 Moon@STONY-BROOK.SCRC.Symbolics.COM APPEND-DOTTED
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Aug 87 19:30:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 207665; Wed 5-Aug-87 21:35:47 EDT
Date: Wed, 5 Aug 87 21:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870727130240.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870805213544.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve.
∂14-Aug-87 1651 unido!ztivax!kolb@seismo.CSS.GOV Redefinition of system functions
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 14 Aug 87 16:51:10 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA13396; Fri, 14 Aug 87 19:51:00 EDT
Received: by unido.uucp with uucp;
Fri, 14 Aug 87 16:01:15 +0100
From: "Dieter Kolb" <unido!ztivax!kolb@seismo.CSS.GOV>
Date: Fri, 14 Aug 87 15:06:16 -0100
Message-Id: <8708141406.AA04604@ztivax.uucp>
Received: by ztivax.uucp; Fri, 14 Aug 87 15:06:16 -0100
To: CL-Cleanup@sail.stanford.edu
Subject: Redefinition of system functions
Problem description:
CLtL allows the redefinition of functions exported from other packages.
Unexperienced programmers may redefine a system function unintentional
which may result into an inconsistent state of the system and cause to
abort.
This happens, for example, if a beginner follows the CL introductory
book "Essential LISP" by Anderson et.al. page 41 where an exercise asks
to define a function make-list. After the redefinition of make-list the
system crashs without returning a message that the function has been
redefined.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Solution:
Redefinition of exported functions should stay allowed. However, some
functions - especially all functions of the package LISP - should be
protected from redefinition. In the case a user tries to redefine such a
function a confirmation should be required.
Protected user functions can be specified in a special list (look-up-
table, value of the variable *protected-functions-from-redefinition*).
Functions from package LISP are protected per se and have not to be
added into this list.
There should be two functions to add and to remove an entry to/from this
list:
protect-function-from-redefinition name
release-function-for-redefinition name
The only function involved in protecting functions from redefinition
seems to be defun. Advising (in the sense of Interlisp) protected
functions, however, should stay allowed.
Dieter Kolb
∂14-Aug-87 2055 FAHLMAN@C.CS.CMU.EDU Redefinition of system functions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87 20:54:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Aug 87 23:54:46-EDT
Date: Fri, 14 Aug 1987 23:54 EDT
Message-ID: <FAHLMAN.12326577897.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dieter Kolb <unido!ztivax!kolb@SEISMO.CSS.GOV>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Redefinition of system functions
In-reply-to: Msg of Fri 14 Aug 87 15:06:16 -0100 from Dieter Kolb <unido!ztivax!kolb at seismo.CSS.GOV>
If there are functions whose redefinition would destroy a particular
Lisp system, I wouldn't mind getting a warning and perhaps even a
correctable error from DEFUN if I am about to lose. The set of
protected functions might include all of the built-in Common Lisp
functions, or it might be a small subset, depending on the details of
the implementation.
There must be a way to turn this protection off, however -- some people
know what they are doing and don't want Lisp to save them. Advising is
one such case, patching over bugs in the built-in functions is another,
and turning a built-in function into a CLOS generic function so that new
behaviors can be added for new types is yet another (once we decide how
much of this will be allowed).
In any case, I think that such protection probably should be considered
an programming-environment issue that is left up to each implementor.
Is there any real need for a standard solution here? I suppose we do
need to make clear that randomly modifying the built-in functions is not
something that is allowed in strictly legal Common Lisp programs.
-- Scott
∂24-Aug-87 1138 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SHADOW-ALREADY-PRESENT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:38:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219273; Mon 24-Aug-87 14:33:31 EDT
Date: Mon, 24 Aug 87 14:33 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 1)
To: Cl-Cleanup@sail.stanford.edu
References: <8708241350.AA23968@ztivax.uucp>, <8708241451.AA28748@HADES.MIT.EDU>
Message-ID: <870824143300.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION
Edit history: Moon 24 Aug 87 new issue (version 1)
Problem description:
The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package. This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.
Proposal SHADOW-ALREADY-PRESENT:WORKS: The SHADOW function always adds
the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is
already present in the package.
Test Case:
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
Rationale:
Page 180 describes a name conflict problem that can occur when calling
the function USE-PACKAGE. The name conflict is between a symbol directly
present in the using package and an external symbol of the used package.
This name conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol. For this
to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list
even when it is already present in the package.
Current practice:
[I have not confirmed any of these myself except Symbolics --Moon]
Symbolics and Spice Lisp behave as proposed here. Kyoto Common Lisp
behaves the other way. Kolb implied, but did not state explicitly,
that Lucid Common Lisp and Xerox Common Lisp behave like KCL. It seems
likely that we will find several implementations in each camp.
Adoption Cost: It should be a one-line change in one function.
Cost of non-adoption: Inconsistency among implementations and lack of a
clear way to resolve the name conflict mentioned in Rationale.
Benefits: Consistency.
Conversion Cost: Technically this would be an incompatible change to
implementations that do not already behave as proposed, however it is
difficult to conceive of a user program that would require any
conversion to cope with the change. Some users might want to remove
kludges that were only necessary to get around the misbehavior of
SHADOW.
Esthetics: The proposal would remove an unnecessary special case,
thus simplifying the language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.
∂24-Aug-87 1808 FAHLMAN@C.CS.CMU.EDU Issue: SHADOW-ALREADY-PRESENT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87 18:07:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 24 Aug 87 21:08:04-EDT
Date: Mon, 24 Aug 1987 21:08 EDT
Message-ID: <FAHLMAN.12329168991.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Cl-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: SHADOW-ALREADY-PRESENT (version 1)
In-reply-to: Msg of 24 Aug 1987 14:33-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I'm in favor of SHADOW-ALREADY-PRESENT:WORKS.
Thanks to Moon for writing this up so quickly.
-- Scott
∂27-Aug-87 1429 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: SHADOW-ALREADY-PRESENT (version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Aug 87 14:28:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 222476; Thu 27-Aug-87 17:30:06 EDT
Date: Thu, 27 Aug 87 17:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 2)
To: Cl-Cleanup@sail.stanford.edu
cc: Jon L White <edsel!bhopal!jonl@labrea.stanford.edu>
References: <870824143300.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870827172932.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION
Edit history: Moon 24 Aug 87 new issue (version 1)
Moon 27 Aug 87 incorporate suggestions from JonL (version 2)
Problem description:
The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package. This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.
SHADOW is said to take symbols as arguments, however only the print-name
is meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package. In addition,
the first argument is allowed to be or contain strings as well as symbols.
The specification "the print name of each symbol is extracted" is to be
modified accordingly.
Test Case:
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
To test the use of strings in place of symbols, change the
third line of the test case to
(shadow "TEST" (find-package 'test-1))
Note the use of capital letters in the string.
Rationale:
Page 180 describes a name conflict problem that can occur when calling
the function USE-PACKAGE. The name conflict is between a symbol directly
present in the using package and an external symbol of the used package.
This name conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol. For this
to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list
even when it is already present in the package.
Since only the print name of a symbol argument is meaningful, a string
should also be accepted. This is particularly useful to avoid problems
when compiling code in one package environment and loading it into a
slightly different package environment, where the symbol that was referred
to at compile time may not be present at load time. This is particularly
important because the symbol referred to by the print name may be changed
by evaluation of the SHADOW form. A close reading of CLtL shows that one
can already use (shadow '#:bar) in place of (shadow 'bar), to achieve much
the same effect as (shadow "BAR"). But the user should not have to play
such games, strings should be accepted.
Current practice:
[I have not confirmed any of these myself except Symbolics --Moon]
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package. Kyoto Common
Lisp, Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the
symbol is already present in the package. It seems likely that we will
find several implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Adoption Cost:
It should be two one-line changes in one function.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve the
name conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Conversion Cost:
Technically this would be an incompatible change to implementations that do
not already behave as proposed, however it is difficult to conceive of a
user program that would require any conversion to cope with the change.
Some users might want to remove kludges that were only necessary to get
around the former misbehavior of SHADOW.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying the
language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.
Epigram:
"Who knows what evil lurks in the hearts of men?"
∂29-Aug-87 1337 Masinter.pa@Xerox.COM [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Aug 87 13:36:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 AUG 87 13:36:54 PDT
Date: 29 Aug 87 13:36 PDT
From: Masinter.pa@Xerox.COM
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: cl-cleanup@sail.stanford.edu
cc: Carnese@SPAR-20.ARPA
Message-ID: <870829-133654-4656@Xerox>
I've given the name "EXPORT-COORDINATION" to this issue. I think this is
an interesting proposal. Comments? (Before Dan writes up a more formal
proposal?)
----- Begin Forwarded Messages -----
Return-Path:
<@SPAR-20.ARPA,@KATYDID.SPAR.CAS.SLB.COM:Carnese@SPAR-20.ARPA>
Received: from SPAR-20.ARPA by Xerox.COM ; 25 AUG 87 13:01:17 PDT
Received: from KATYDID.SPAR.CAS.SLB.COM (KATYDID.#Internet) by
SPAR-20.ARPA with TCP; Tue 25 Aug 87 12:59:13-PDT
Date: Tue, 25 Aug 87 12:59 PDT
From: Dan Carnese <Carnese@SPAR-20.ARPA>
Subject: proposal
To: masinter.pa
Message-ID: <870825125906.2.CARNESE@KATYDID.SPAR.CAS.SLB.COM>
Thanks for the information. I didn't realize that proposals were
required
to be in such a detailed format but of course that makes sense.
I think the problem can be "symbolized" as
multiple-forms-for-exported-defined-symbols. Its definition could be:
Exporting a defined symbol currently requires two seperate
forms:
one to give a value to the symbol and another to cause the
symbol
to be on a package export list. These two forms must be kept in
sync as the program evolves.
The benefit would be:
Explicit export lists could be eliminated in many cases.
The thrust of the discussion would be:
This is an extremely straightforward addition, one which could
be
implemented by macros that would simply expand to an export and
an
existing definition form. Only DEFSTRUCT* would involve actual
programming, to process the additional defstruct and slot
options.
The proposal does not completely eliminate the need for explicit
calls to EXPORT for two reasons. First, it is sometimes useful
to
export symbols for which no definition forms are applicable,
e.g.,
to be used as arguments to functions. Second, explicit exports
of
defined symbols are still needed in the following case. Suppose
A
and B are packages, A defines an external symbol F, and B uses
A.
Suppose further that F appears in a form being read into package
B,
and that this form is to be read before the definition of F is
loaded. In this case, an explicit export of F must occur, to
avoid
F being inappropriately interned in B.
Does this sound reasonable?
-- Dan
----- End Forwarded Messages -----
∂29-Aug-87 1439 RAM@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Aug 87 14:39:04 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 29 Aug 87 17:40:55-EDT
Date: Sat, 29 Aug 1987 17:40 EDT
Message-ID: <RAM.12330441992.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Masinter.pa@XEROX.COM
Cc: Carnese@SPAR-20.ARPA, cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 29 Aug 1987 16:36-EDT from Masinter.pa at Xerox.COM
The idea has obvious intuitive appeal, since people tend to think of
exporting definitions rather than names. Unfortunately, I think that
there is likely to be some messy semantics due to name resolution
happening at read time and the implicit package manipulation happening
later on. The semantics of package manipulation with respect to
compile-file/load is currently not defined. [Except perhaps in some
vague language that suggests the semantics of loading the source are
preserved, which is clearly wrong.] It is certainly naive to suppose
that a macro can expand into arbirary package manipulation code and
"the right thing" will happen.
I think that exporting symbols from the current package happens to be
safe as long as all the code in a file is restricted to one package,
but I certainly don't want to have to figure out which of all possible
kinds of package manipulation will break what possible reasonable
compiler organizations.
You should also be careful that you aren't thinking of this issue in
terms of "top-level defining forms", since I am convinced that the
notion of a "top-level form" is semantically bankrupt. Although some
forms are most often used at "top-level" (however defined), the
semantics of those forms are a result of its evaluation, and a form can
be evaluated anywhere. Consider the semantics of:
(if <whatever>
(defun-exported foo ...))
Consider the possible range of implementations such as "compilers" and
"interpreters". Is Foo {always | never | sometimes} exported at
{read | macroexpand | compile | load | run} time?
I currently favor requiring all package manipulation to be done at the
head of the file. This has the advantage that it allows compilers and
editors to find all stuff pertinent to read-time semantics without
having to go through the motions of compiling the entire file.
Of course, it would be possible to have an automatic exporting feature
without allowing users to have package-hacking macros.
Rob
∂02-Sep-87 1926 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 2 Sep 87 19:26:25 PDT
Date: Wed 2 Sep 87 19:25:58-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12330441992.BABYL@>
Message-ID: <12331542476.10.CARNESE@SPAR-20.ARPA>
Although not explicitly stated in the message Larry forwarded, the proposal
is for def...* forms that export the defined symbols from their packages.
Of course, your observations are valid about the non-clarity of the value
of *package* and of when a symbol is actually defined. But they don't seem
directly relevant to this proposal, since they describe problems in the
current language definition. So long as the export occurs just after the
cell is filled, I don't think we're adding to the existing murkiness.
-------
∂02-Sep-87 1952 FAHLMAN@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87 19:52:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Sep 87 22:52:27-EDT
Date: Wed, 2 Sep 1987 22:52 EDT
Message-ID: <FAHLMAN.12331547288.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987 22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>
I'll stay out of the argument about whether it is a good idea to scatter
the exports (implicit or explicit) all through the file, rather than
requiring all the exports to occur at the start of each file. This is
tied up with some big questions about the compiler, and it can't really
be settled in isolation.
Just for the record, though, I would strongly oppose any proposal to use
DEF...* for naming the def-exporting forms. The last thing we need in
this language is to start sticking stars and other meaningless
decorations on the end of symbols whenever we want to say "different in
some way that I know and you'll have to guess". There's already some of
this kind of thing in the language, held over from other Lisps, but we
shouldn't extend the practice.
-- Scott
∂03-Sep-87 1118 RAM@C.CS.CMU.EDU [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 11:17:57 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Sep 87 14:18:04-EDT
Date: Thu, 3 Sep 1987 14:17 EDT
Message-ID: <RAM.12331715786.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987 22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>
Actually, having the defining form export the symbol from its home
package is more problematic than exporting from the current package.
Consider a code fragment like:
(in-package 'a :use '(lisp b))
...
(defun-exported b::foo ...)
foo
What package is the following "foo" in? Obviously the DEFUN-EXPORTED
and the "foo" could be in the same form, so under some circumstances,
that "foo" couldn't possibly refer to B:FOO, yet if the compiler
happened to process the DEFUN-EXPORTED before the "foo" was read, then
it would be B:FOO.
To say that these things are "just problems in the current language
definition" doesn't avoid the problem. Adding new langauge features
is language design, and a language designer must consider how each
language feature will affect his ability to properly define the
language. I am suggesting that this feature would significantly
complicate the language definition for what seems to me to be little
gain.
Rob
∂04-Sep-87 1030 edsel!bhopal!jonl@labrea.stanford.edu [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:30:27 PDT
Received: by labrea.stanford.edu; Fri, 4 Sep 87 10:11:04 PDT
Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0)
id AA22223; Fri, 4 Sep 87 09:08:33 PDT
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA04816; Fri, 4 Sep 87 09:08:14 PDT
Date: Fri, 4 Sep 87 09:08:14 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8709041608.AA04816@bhopal.edsel.com>
To: labrea!Ram%C.CS.CMU.EDU@labrea.stanford.edu,
labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!CARNESE%SPAR-20.ARPA@labrea.stanford.edu,
labrea!cl-cleanup%SAIL@labrea.stanford.edu
In-Reply-To: navajo!Ram@C.CS.CMU.EDU's message of Thu, 3 Sep 1987 14:17 EDT <RAM.12331715786.BABYL@>
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
One of the good qualities I liked about Mesa (the Xerox answer to Pascal)
was the way programmers were encouraged to write a "defs" file for every
"module" -- basically, this file declares the exportable items, along with
their syntax (no code, however), and also mentions the importations (a bit
like CL's REQUIRE). I don't know how much of a pain it was for programmers
to produce correct modules under this regimen, but it sure made it a heck
of a lot easier to read someone else's code.
I, for one, in my regular work wind up reading a lot of other people's
code; and most of my code is eventually read by other people. Hence I
would prefer a direction for Common Lisp which facilitated the ability
to read other people's code, even at the expense of some programming
conveniences. This means that having all the "7 extrememly randoms"
at the beginning of a file (except for PROVIDE) is a much better
solution than having them sprinkled around random other files in
random other modules.
-- JonL --
∂04-Sep-87 1047 CARNESE@SPAR-20.ARPA Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:47:43 PDT
Date: Fri 4 Sep 87 10:15:49-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12331715786.BABYL@>
Message-ID: <12331966613.10.CARNESE@SPAR-20.ARPA>
Return-Path: <RAM@C.CS.CMU.EDU>
Received: from C.CS.CMU.EDU by SPAR-20.ARPA with TCP; Thu 3 Sep 87 11:18:03-PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Sep 87 14:18:04-EDT
Date: Thu, 3 Sep 1987 14:17 EDT
Message-ID: <RAM.12331715786.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987 22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>
Actually, having the defining form export the symbol from its home
package is more problematic than exporting from the current package.
Consider a code fragment like:
(in-package 'a :use '(lisp b))
...
(defun-exported b::foo ...)
foo
What package is the following "foo" in? Obviously the DEFUN-EXPORTED
and the "foo" could be in the same form, so under some circumstances,
that "foo" couldn't possibly refer to B:FOO, yet if the compiler
happened to process the DEFUN-EXPORTED before the "foo" was read, then
it would be B:FOO.
To say that these things are "just problems in the current language
definition" doesn't avoid the problem. Adding new langauge features
is language design, and a language designer must consider how each
language feature will affect his ability to properly define the
language. I am suggesting that this feature would significantly
complicate the language definition for what seems to me to be little
gain.
Rob
Sorry, but I'm still not clear on how this extension makes the situation
any more complicated. What I understand you to be saying is that the
semantics of your example would not be well-defined in the case where these
are not top-level forms. Of course, you're right. But since any code
involving the new constructs can be expanded into existing constructs
(e.g., by replacing the defun-exported with a defun followed by an export),
the proposal doesn't introduce any new kinds of problematic situations.
Thus, it is difficult to argue that the language definition would be made
more complicated by having such expansions predefined.
With regard to the naming issue that Scott raised, the use of "-exported"
as a suffix seems quite reasonable. I'm happy to accede to a change that
increases readability.
-------